tag:blogger.com,1999:blog-14452566293577465362024-03-19T10:07:01.947+02:00KäytettävyysnavigoijaTimo JokelaTimo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.comBlogger178125tag:blogger.com,1999:blog-1445256629357746536.post-46846132448664014902023-10-19T16:33:00.031+03:002023-10-20T11:07:20.434+03:00Uusia potilastietojärjestelmiä kilpailutetaan - mutta saadaanko niistä helppokäyttöisiä?<p><span style="color: #191919; font-family: font000000002add18db;">Länsi-Uudenmaan </span><span style="color: #191919; font-family: PublicoTextLCGWeb;">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.</span></p><p><span style="background-color: white; color: #191919; font-family: PublicoTextLCGWeb;">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. </span></p><div><span style="color: #191919; font-family: PublicoTextLCGWeb;">Kirjoitin - pitkästä aikaa - asiasta <a href="https://www.hs.fi/mielipide/art-2000009915583.html" target="_blank">mielipidekirjoituksen Hesariin</a> (ks. myös kuva). </span></div><div><span style="color: #191919; font-family: PublicoTextLCGWeb;"><br /></span></div><div><span style="color: #191919; font-family: PublicoTextLCGWeb;">Saa nähdä, kilpailuttavatko kyseiset sairaanhoitopiirit potilastietojärjestelmää niin, että helppokäyttöisyyttä aidosti edellytettäisiin. Jos näin tekisivät, olisivat kyllä uranuurtajia. </span></div><div><span style="color: #191919; font-family: PublicoTextLCGWeb;"><br /></span></div><div><span style="color: #191919; font-family: PublicoTextLCGWeb;">J</span><span style="color: #191919; font-family: PublicoTextLCGWeb;">os 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</span><span style="color: #191919; font-family: PublicoTextLCGWeb;">äytettävyyttä voidaan toki näinkin saada, mutta vain hyvällä tuurilla tai kalliilla lisätilauksilla. </span></div><div><span style="color: #191919; font-family: PublicoTextLCGWeb;"><br /></span></div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOpIaazYA1CfIBBuQ4LEbb-ZTn2PVkc0ik5sDrk2jovsX0Ul-1g1FuyBDmFq43luG7mdZDLdMcxYPYkXriFpeUy-1OVPish3ntSiuc2JjpFQ_OyLpe7zj8eufP-le7y1w-CA92Bnw4hwrLInxMJyouF0cQY7e_BKMeyhFhBjLb3L5z-6qKr4OrrhkODg/s3762/IMG_7846.jpeg" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" data-original-height="1777" data-original-width="3762" height="302" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOpIaazYA1CfIBBuQ4LEbb-ZTn2PVkc0ik5sDrk2jovsX0Ul-1g1FuyBDmFq43luG7mdZDLdMcxYPYkXriFpeUy-1OVPish3ntSiuc2JjpFQ_OyLpe7zj8eufP-le7y1w-CA92Bnw4hwrLInxMJyouF0cQY7e_BKMeyhFhBjLb3L5z-6qKr4OrrhkODg/w640-h302/IMG_7846.jpeg" width="640" /></a></div><br /><span style="color: #191919; font-family: PublicoTextLCGWeb;"><br /></span></div><div><span style="color: #191919; font-family: PublicoTextLCGWeb;"><br /></span></div><div><span style="color: #191919; font-family: PublicoTextLCGWeb;"><br /></span></div>Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com0tag:blogger.com,1999:blog-1445256629357746536.post-25258418389062011262022-10-14T08:22:00.031+03:002022-10-21T06:28:01.907+03:00Vaikuttavuus on tärkeää - mutta miten se pitäisi ottaa huomioon julkisissa hankinnoissa?<p><b>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 </b><b>käytön aikana, ehkä paljonkin </b><b>kehitystyön päättymisen jälkeen. </b><b>Sen sijaan haluttu vaikuttavuus olisi määritettävä tarjouspyyntöön sellaisilla alemman tason vaatimuksilla,</b><b> (1) </b><b>joiden </b><b>saavuttaminen </b><b>voidaan todentaa heti kehitystyön päättyessä ja (2) </b><b>joiden </b><b>saavuttaminen </b><b>tarkoittaa riittävän luotettavasti, että saavutetaan myös haluttu vaikuttavuus. </b></p><p>Olin mukana 13.10.2022 <a href="https://hankintayhdistys.fi" target="_blank">Hankinta-yhdistyksen</a> aamukahveilla, jonka aiheena oli <i>Kustannusvaikuttavuuden laskenta osana hankintaprosessia</i>. </p><p>Aihe on sikäli kiinnostava, että itse olen korostanut<i> käytettävyyden</i> <i>vaikuttavuuden</i> määrittämisen tärkeyttä (esimerkiksi <a href="https://drive.google.com/file/d/1XcP_mdqcVkBncL-Di-1VY1V9X-CMDr-Z/view?usp=sharing" target="_blank">tässä Sytyke-lehden artikkelissa</a>). Tarkoittaa sitä, että ensin pitäisi määrittää haluttu käytettävyyden vaikuttavuus, ja vasta sen jälkeen käytettävyysvaatimukset. </p><h4 style="text-align: left;">Aamukahvien esimerkki: toimittajan palkitseminen vaikuttavuuden saavuttamiseksi</h4><p>Aamukahvien keskustelussa kerrottiin esimerkki julkisen hallinnon tietojärjestelmähankinnasta, jossa vaikuttavuus oli otettu huomioon näin:</p><p></p><ul style="text-align: left;"><li>Toimittajaa palkittiin sen mukaan, <i>kuinka</i> <i>paljon palvelu houkuttelisi käyttäjiä</i>. Siis mitä enemmän käyttäjiä palvelulla, sitä enemmän palkitaan toimittajaa. Muistaakseni tavoite oli 60.000 käyttäjää. </li><li>Tässä ei siis suoraan vaikuttavuutta mitattu rahassa, mutta vaikuttavuudesta kyse on joka tapauksessa.</li></ul>Oletan, että tämä palkitsemismalli oli osana tarjouspyyntöä; tosin tästä ei ollut puhetta tilaisuudessa.<div><br /><div><h4>Toimittajan palkitseminen vaikuttavuusmittarilla - miksi voi olla ongelma?</h4></div><div><div><br /></div><div>Edellä mainitussa lähestymistavassa on yksi periaatteellinen ongelma. Vaikuttavuuden käyttäminen tavoitteena tai palkitsemisperusteena (tarjouspyynnössä) on ongelma sitä kautta, että<i> vaikuttavuuden saavuttamista ei voi todentaa kehitystyön päättyessä: </i></div><div><ul style="text-align: left;"><li>Vaikuttavuushan tulee esiin vasta ajan myötä, kuten edellä mainitussa esimerkissä käyttäjien lukumäärä. </li><li>Käytännössä tarkoittaa sitä, että haluttu vaikuttavuuden saavuttaminen jää arvoitukseksi siinä vaiheessa, kun kehitystyö on päättynyt. </li></ul></div></div><div>Jos käy niin, että esimerkin järjestelmä ei houkuttele käyttäjiä, niin tilaajalta säästyy toimittajan bonusrahat. <i>Mutta mitä tilaaja tekee järjestelmällä, jota käyttäjät eivät käytä?</i></div><div><br /></div><div>Jos ottaa <b>konkreettisemman esimerkin</b>, niin moni varmaan muistaa muutaman vuoden takaisen yrityksen käyttää <i>äänestyskonetta</i> kunnallisvaaleissa. Sehän päättyi <a href="https://www.mtvuutiset.fi/artikkeli/vihtiin-karkkilaan-ja-kauniaisiin-uudet-kuntavaalit/1870834" target="_blank">epäonnistumiseen</a>, kun jotkut äänestäjät jättivät epähuomiossa äänestysprosessin kesken (kyseessä siis selkeä käytettävyysongelma...).</div><div><br /></div><div>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 <i>äänestyskoneen *pitää* toimia </i>vaaleissa<i>. </i>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). </div><div><br /></div><h4 style="text-align: left;">Miten sitten ottaa vaikuttavuus huomioon hankinnoissa?</h4><div><br /></div><div><i>Tavoitteellista pitäisi olla, että haluttu vaikuttavuus voitaisiin mitata - riittävän luotettavasti - heti kehitystyön päättyessä. </i></div><div><br /></div><div>Miten tämä voidaan tehdä? </div><div><br /></div><div>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. </div><div><br /></div><div>Sitten perusratkaisu vaatimusten määrittämiselle tarjouspyyntöön on, että määritetään <i>sellaiset</i> <i>alemman tason vaatimukset</i>, että</div><div><ol style="text-align: left;"><li>vaatimusten saavuttaminen voidaan todentaa kehitystyön päättyessä</li><li>vaatimusten saavuttaminen tarkoittaa riittävän luotettavasti sitä, että myös haluttu vaikuttavuus saavutetaan</li></ol></div><div>Kummatkin edellämainitut esimerkit (tietojärjestelmä, äänestyskone) ovat sellaisia, joissa haluttu vaikuttavuus (paljon käyttäjiä, onnistuneet vaalit) <i>riippuu suoraan järjestelmän käytettävyydestä</i>. </div><div><br /></div><div>Alemman tason vaatimuksia olisivat silloin<i> käytettävyysvaatimukset</i>. 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 <a href="https://kaytettavyysnavigoija.blogspot.com/2011/06/mita-ovat-kaytettavyysvaatimukset.html">tässä</a>). </div><div><br /></div><div>Hankkijan on tehtävä sisäisesti käytettävyysvaatimusten analyysi- ja määrittämistyö ennen hankintaa. Tarjouspyyntöön määritettäisiin sitten <i>käytettävyysvaatimukset (</i>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. </div><p></p></div>Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com0tag:blogger.com,1999:blog-1445256629357746536.post-16571674827242066552022-09-06T11:34:00.007+03:002022-09-06T11:41:43.897+03:00Seitsemän (7) väärää ja neljä (4) oikeaa tapaa ottaa käyttäjät mukaan järjestelmän hankinnassa ja kehityksessäKirjoitin elokuussa <a href="https://kaytettavyysnavigoija.blogspot.com/2022/07/lappican-potilastietojarjestelman.html" target="_blank">blogikirjoituksen</a> 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. <div><br /></div><div>Olen kirjoittanut asiasta aiemmin seikkaperäisesti, esimerkiksi kappaleen <a href="https://drive.google.com/file/d/1mc7JBz7bzhemTYlxAG0CgNHn3Cu4WneS/view?usp=sharing" target="_blank">Miten käyttäjät mukaan tietojärjestemäkehitykseen - ja miten ei? </a>Eduskunnan tulevaisuusvaliokunnan julkaisuun <a href="https://www.eduskunta.fi/FI/naineduskuntatoimii/julkaisut/Documents/tuvj_12+2014.pdf" target="_blank">Katse kohti IT-etiikkaa</a>. </div><div><br /></div><div>Nyt sitten ajattelin kerrata lyhyesti: luettelo niin <i>laadullisesti kuin eettisesti</i> <i>vääristä ja oikeista</i> tavoista. <div><br /></div><div><i>Väärät</i> tavat ottaa käyttäjät mukaan: </div><div><p style="font-stretch: normal; line-height: normal; margin: 0px;"></p><ol style="text-align: left;"><li><span style="font-family: inherit;">Käyttäjiä pyydetään määrittelemään järjestelmän ominaisuuksia ja kertomaan mielipiteitä tulevasta järjestelmäst</span><span style="font-family: inherit;">ä </span></li><li><span style="font-family: inherit;">Käyttäjiä pyydetään määrittelemään vaatimukset järjestelmälle </span></li><li><span style="font-family: inherit;">Suunnitellaan yhdessä käyttäjien kanssa</span></li><li><span style="font-family: inherit;">Käyttäjiä pyydetään antamaan käyttöliittymistä laadullisia ”asiantuntija-arviointeja” </span></li><li><span style="font-family: inherit;">Käyttäjiä pyydetään katselmoimaan käyttöliittymiä </span></li><li><span style="font-family: inherit;">Käyttäjiltä kysytään ehdotuksia paremmiksi suunnitteluratkaisuiksi </span></li><li><span style="font-family: inherit;">Käyttäjät laitetaan pisteyttämään järjestelmän käytettävyys toimittajien esittämien demojen perusteella </span></li></ol><p></p><p style="font-stretch: normal; line-height: normal; margin: 0px;"><span style="font-family: inherit;"><i>Oikeat</i> tavat ottaa käyttäjät mukaan:</span></p><p style="font-stretch: normal; line-height: normal; margin: 0px;"></p><ol style="text-align: left;"><li><span style="font-family: inherit;">Sisällölliset haastattelut: käyttäjiltä haastatellaan heidän työstään tai ammattiosaamisestaan </span></li><li><span style="font-family: inherit;">Käyttäjiä havainnoidaan heidän työssään </span></li><li><span style="font-family: inherit;">Käyttäjiä pyydetään käytettävyystestien testihenkilöiksi </span></li><li><span style="font-family: inherit;">Käyttäjiltä kysytään heidän käyttökokemuksestaan </span></li></ol><div>Jos nämä vetää yhteen <i>periaatteiksi</i>, niin voisi tiivistää, että käyttäjät otetaan mukaan laadullisesti ja eettisesti oikein, kun </div><div><ul style="text-align: left;"><li>Käyttäjien ei pidä olla missään muussa roolissa kuin <i>oman ammattinsa ja työtehtävänsä edustajana</i> (käyttäjät ovat siis ainoastaan omalla mukavuusalueellaan)</li><li>Käyttäjiä <i>ei pidä vastuuttaa </i>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ä. </li></ul>Jos kiinnostaa, miten tehdään tuloksellisesti ja tehokkaasti sisällöllisiä haastatteluja ("Oikeat tavat" kohta 1), olen kirjoittanut menetelmästä kirjan <a href="https://www.ketteratkirjat.fi/kirjat/36229" target="_blank">Kohdemaailma-analyysi</a>. Menetelmässä kerrotaan, miten haastatella asiakkaita niin, että saadaan nopeasti syvällinen ymmärrys asiakkaan tarpeista samalla, kun haastateltavia kohdellaan eettisesti oikein. </div><div><br /></div><div>PS. Jos sinulla on kommentoitavaa ym. oikeisiin ja vääriin tapoihin (tai muuten kirjoitukseen), niin mielellään sellaisia kuulisin!</div><p></p></div></div>Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com2tag:blogger.com,1999:blog-1445256629357746536.post-35065608346468768642022-07-27T08:54:00.021+03:002022-07-30T07:30:15.240+03:00Lappican potilastietojärjestelmän tarjouspyyntö: ei uutta käytettävyyden suhteen<p><span style="font-family: inherit;"><i>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. </i></span></p><p><span style="font-family: inherit;"><i>HUOM! Korostan vielä, että t</i></span><i>ätä analyysia ei pidä ottaa erityiseksi kritiikiksi Lappica Oy:ta kohtaan. Tarjouspyyntö sattui vain osumaan silmääni, kun kyse on potilastietojärjestelmästä. O</i><i style="font-family: inherit;">len s</i><i>eurannut aika </i><i style="font-family: inherit;">tiiviisti Apotti-potilastietojärjestelmän hankintaa (monet kirjoitukset tässä blogissa, ja esimerkiksi <a href="https://kaytettavyysnavigoija.blogspot.com/2022/01/artikkelini-helsingin-sanomissa-kokoelma.html">Helsingin Sanomissa</a>). </i><i>O</i><i style="font-family: inherit;">tin tämän tarjouspyynnön tarkasteluun ihan tämän kiinnostuksen pohjalta. </i></p><h3>Mistä kyse</h3><p><span style="font-family: inherit;">Pääkaupunkiseudun Apotti-potilastietojärjestelmän käytettävyysongelmat ovat tunnettuja. Nyt Apotista on tekeillä jopa <a href="https://yle.fi/uutiset/3-12551082?utm_source=facebook&utm_campaign=yleuutiset&utm_medium=social&fbclid=IwAR2PKUVYHISpLdHwxWCKrbs9FLskqunNJcvbFt5FPq9dAyZaJgQU54MmW8Y" target="_blank">kantelu</a>. </span></p><p><span style="font-family: inherit;">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 </span>edellytetty <span style="font-family: inherit;">oikealla tavalla tarjouspyynnössä (analyysia esimerkiksi </span><a href="http://kaytettavyysnavigoija.blogspot.com/2020/05/apotin-hankinnassa-tehtiin-kaksi-vanhaa.html">tässä</a>). <span style="font-family: inherit;">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ä. </span></p><p><span style="font-family: inherit;">Nyt sitten osui sattumoisin silmiini uusi potilastietojärjestelmän kilpailutus, kun Lapin sairaanhoitopiirin </span><a href="https://www.hankintailmoitukset.fi/fi/public/procurement/71906/notice/102931/overview" target="_blank">tarjouspyyntö</a><span style="font-family: inherit;"> on julkaistu</span><span style="font-family: inherit;"> (luettavissa luultavasti 15.8.2022 asti, jolloin on tarjousten viimeinen jättöpäivä). </span></p><p><span style="font-family: inherit;">Kun kyseessä on potilastietojärjestelmä, tarjouspyyntö kiinnosti sen verran, että analysoin sitä seuraavassa käytettävyyden kannalta. </span></p><h3 style="text-align: left;">Miten käytettävyys määräytyy yleensä tarjouspyynnöissä?</h3><div>Tarjouspyynnössä halutun käytettävyyden tason määrittä kaksi asiaa: </div><div><ul><li>miten käytettävyysasioita vaaditaan <i>pakollisissa vaatimuksissa</i></li><li>miten käytettävyysasioita on sisällytetty <i>vertailuperusteisiin</i>, ja mitkä ovat näiden <i>painoarvot</i> vertailussa</li></ul></div><div><span style="font-family: inherit;">Valintaprosessi menee sitten lyhyesti ilmaistuna: </span></div><div><span style="font-family: inherit;"><br /></span></div><div> 1. Tarkistetaan, täyttyvätkö pakolliset vaatimukset: </div><div><ul><li>Jos täyttyvät, tarjous etenee vertailuvaiheeseen</li><li>Jos eivät täyty, tarjous tipahtaa pois kilpailutuksesta</li></ul></div><div style="text-align: left;"> 2. Lasketaan yhteen vertailupisteet. Tarjouskilpailun voittaja on se, joka saa eniten vertailupisteitä. </div><div style="text-align: left;"><br /></div><div style="text-align: left;">Käytännössä keskeisin asia on se, miten käytettävyys on määritetty pakollisiin vaatimuksiin. <i>Hyvin valmistellussa tarjouspyynnössä kaikki käytettävyysasiat on pakollisissa vaatimuksissa.</i> Vain erityisissä tapauksissa käytettävyysasioita on perusteltua laittaa vertailuperusteisiin. </div><div style="text-align: left;"><br /></div><h3 style="text-align: left;">Lappican tarjouspyynnön sisällön kuvausta</h3><p><span style="font-family: inherit;">Tarjouspyynnön johdanto-osassa lukee esimerkiksi: </span></p><div class="page" title="Page 2"><div class="layoutArea"><div class="column"><ol start="0" style="list-style-type: none; text-align: left;"><li><p></p></li></ol><p><i><span style="font-family: inherit;">"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... </span></i><i><span style="font-family: inherit;">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."</span></i></p><p><span style="font-family: inherit;"><b>Tällä perusteella käytettävyys on hankkijalle tärkeä asia.</b></span></p><p><span style="font-family: inherit;">Mutta. On huomattava, että <i>tällaisella epäformaalilla johdantotekstillä ei ole mitään merkittävyyttä kilpailutuksessa</i>. 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ä. </span></p><div style="text-align: left;"><h4><span style="font-family: inherit;">Mitä käytettävyysasioita vaaditaan tarjouspyynnössä?</span></h4></div><div style="text-align: left;"><span style="font-family: inherit;">Tässä tarjouspyynnössä vertailuperusteet ovat:</span></div><div style="text-align: left;"><ul style="text-align: left;"><li><i>laadulliset vaatimukset</i> 40 pistettä, joista</li><ul><li>"<i>pisteytettävät vaatimukset</i>" 35 pistettä </li><li><i>projektisuunnitelma</i> 5 pistettä</li></ul><li><i>hinta</i> 60 pistettä</li><li>(yhteensä 100 pistettä)</li></ul><div>"Pisteytettävät vaatimukset", samoin kuin pakolliset vaatimukset on esitetty samassa, isossa excel-taulukossa</div><div><ul style="text-align: left;"><li>pakolliset vaatimukset tarkoittavat, että toimittajan on <i>pakko</i> täyttää ne (muuten tipahtaa pois kilpailutuksesta)</li><li>pisteytettävät vaatimukset tarkoittavat, että toimittajan ei ole pakko niitä täyttää, mutta niiden täyttäminen tarkoittaa <i>enemmän pisteitä</i> vertailuperusteisiin ja sitä kautta paremmat mahdollisuudet voittaa kilpailutus</li></ul><div>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: <i>Työterveyshuolto, Ajanvaraus, Ilmoittautuminen, Lausunnot ja lähetteet</i> jne. </div><div><br /></div><div>Ja on siellä sitten yksi välilehti nimeltään <i>Käyttäjälähtöisyys</i>. Alla kuvankaappaus taulukon ko. kohdasta.</div></div><div><br /><div class="separator" style="clear: both; text-align: left;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgeQuvECDVt3kdOJ5G8xHochKEOpJg1cFo2GrF20uFY_YKWK2x4sHl7qPOQObX9qUivQr1iMQAXgKW7OK_TOyWf5wirvZKAXuej7OPsNAT0mHrG-e9AtFLcUervWzDDS6RA3wA7AdhodYdRBKJSAuT1AmuqF3-xr9PjGENHjQCYp7BLub52kNFA7v4/s1124/Na%CC%88ytto%CC%88kuva%202022-7-27%20kello%208.01.59.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="523" data-original-width="1124" height="308" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgeQuvECDVt3kdOJ5G8xHochKEOpJg1cFo2GrF20uFY_YKWK2x4sHl7qPOQObX9qUivQr1iMQAXgKW7OK_TOyWf5wirvZKAXuej7OPsNAT0mHrG-e9AtFLcUervWzDDS6RA3wA7AdhodYdRBKJSAuT1AmuqF3-xr9PjGENHjQCYp7BLub52kNFA7v4/w662-h308/Na%CC%88ytto%CC%88kuva%202022-7-27%20kello%208.01.59.png" width="662" /></a></div></div><div style="text-align: left;"><br /></div><h3 style="text-align: left;">Sisältäänkö tarjouspyyntö käytettävyysvaatimuksia?</h3><div>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 <a href="http://kaytettavyysnavigoija.blogspot.com/2011/08/mika-olikaan-kaytettavyyden-maaritelma.html">täällä.</a></div><div><br /></div><div><div>Kun tarkastelee "Käyttäjälähtöisyys" -vaatimuksia, niin useimmissa vaatimuksissa lukee, että jokin asia</div><div><ul style="text-align: left;"><li>"<i>pitää voida tehdä</i>" </li><li>"<i>pitää olla mahdollista</i>" </li><li>"<i>pitää päästä tekemään</i>" </li><li>tms. </li></ul>Tällaiset muotoilut tarkoittavat yleensä <i>toiminnallisia vaatimuksia eivätkä käytettävyysvaatimuksia</i>. Ja nämä ovat eri asioita. </div><div><br /></div><div>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ä: </div><div><br /></div></div></div></div></div></div><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px;"><div class="page" title="Page 2"><div class="layoutArea"><div class="column"><div style="text-align: left;"><div><div style="text-align: left;"><i>Voiko vaatimuksen täyttää niin, että sen toteutus on vaikeakäyttöinen? </i></div></div></div></div></div></div></blockquote><div class="page" title="Page 2"><div class="layoutArea"><div class="column"><div style="text-align: left;"><div><div><br /></div><div>Jos vastaus on kyllä, niin kyseessä ei ole käytettävyysvaatimus. </div><div><div><br /></div><div></div><div><div>Otetaan esimerkiksi yllä olevasta taulukosta vaatimus <i>Käy_03: PTJ:ssä on sisäinen ohjeistus hakutoiminnolla</i>. Kysytään sitten, <i>voiko kyseisen vaatimuksen täyttää siten, että toteutus on vaikeakäyttöinen? </i></div><div><br /></div><div>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. </div><div><br /></div><div><div><i>Huom</i>. 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. </div><div><br /></div></div><div>Ainoastaan taulokon viimeinen vaatimusta - <i>Käy_36: Tutkimustulosten ja lähetteiden palautteiden siirtyy automaattisesti sijaistajalta seuraavalle sijaistajalle</i> - 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. </div></div></div></div><div><br /></div><div>Jos ottaa esiin toisen piirteen vaatimuksista, niin yksi käyttäjäryhmä nousee ylitse muiden: peräti 8 vaatimuksen käyttäjäryhmä on <i>pääkäyttäjät. </i>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. </div><div><br /></div><h4 style="text-align: left;">Pakolliset vaatimukset vs. pisteytettävät vaatimukset</h4><div><br /></div><div>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ä. </div><div><br /></div><div>Yleisesti tällainen jako on vähän keinotekoinen. Parempi ratkaisu olisi yksinkertaisesti, että <i>kaikki vaatimukset olisivat pakollisia</i>. 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. </div><div><br /></div><h3 style="text-align: left;">Muut vaatimuskategoriat</h3><div>Tarjouspyynnössä on siis noin 15 samantyyppistä vaatimuslistaa kuin <i>Käyttäjälähtöisyys</i> -vaatimukset. </div><div><br /></div><div>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: </div><div><ul style="text-align: left;"><li><i>Käyttäjät voivat valita valmiin kalenteripohjan kalenterimallista tai luoda oman kalenteripohjan erilaisia aikatyyppejä käyttäen</i></li><li><i>Ammattilainen voi tarkastella PTJ:n ajanvarausnäkymässä olevia aikatauluja esimerkiksi päivä- ja viikkokohtaisesti</i></li><li><i>Lääkärillä on oltava tieto uudistamista odottavien lääkemääräysten uudistuspyynnön voimassaolosta</i></li></ul><div>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. </div></div><div><br /></div><h3 style="text-align: left;">Yhteenveto</h3><div>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: </div><div><br /></div><div>"<i>helppokäyttöinen, käyttäjää ohjaava ja ammattilaisten työtä helpottava..</i><i>. 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".</i></div><div><br /></div><div>Mutta. Eipä tämä tarjouspyyntö ole sen huonompi käytettävyyden osalta kuin julkisen hallinnon tarjouspyynnöt yleensäkään. </div><div><br /></div><div>Ja itse asiassa tässä tarjouspyynnössä on hyviäkin puolia: </div><div><ul style="text-align: left;"><li>Tarjousten käsittely <i>ei vie käytettävyyden osalta paljon resursseja</i> - 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. <a href="https://kaytettavyysnavigoija.blogspot.com/2016/11/massiivia-kaytettavyystesteja-ja.html">Lue tästä lisää</a>.</li></ul><ul style="text-align: left;"><li>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 <b>ei</b> takaa tuotteen laatua). Eli siinäkään mielessä tämä tarjouspyyntö ei missään tapauksessa ollut pahimmasta päästä. </li></ul><br /><div><h3>Mikä olisi oikea tapa sisällyttää käytettävyys tarjouspyyntöön?</h3></div></div><div>Jotta tarjouspyyntö edellyttäisi aidosti käytettävyyttä, niin </div><div><ul style="text-align: left;"><li>Käytettävyys olisi sisällytettävä <i>pakollisiin vaatimuksiin. </i>Vain erityistapauksissa käytettävyyttä voisi olla valintakriteereissä, ja silloinkin korkeintaan pienellä painoarvolla. </li><li>Käytettävyysvaatimukset olisi määritettävä suhteessa <i>käyttäjien suoriutumiseen. </i>Silloin, kun käyttäjät suoriutuvat tehtävistään riittävän hyvin, järjestelmä on käytettävyydeltään hyvä. </li></ul><div>Miten sitten määritetään käytettävyysvaatimukset suhteessa käyttäjien suoriutumiseen? Sitä varten tarvitsee määrittää</div></div><div><ul style="text-align: left;"><li><i>mittarit</i>: millä mittarilla mitataan käyttäjien suoriutumista</li><li><i>tavoitetasot</i>: mikä mittaustulos ko. mittarilla on riittävän hyvä</li><li><i>mittausinstrumentit</i>: miten mittaus käytännössä suoritetaan (yleensä tämä tarkoittaa käyttäjätestejä, mutta ei välttämättä)</li></ul><div>Ja vielä pitää ottaa huomioon, että mitkä tahansa mittarit, tavoitetasot ja instrumentit eivät kelpaa. Käytettävyysvaatimusten on oltava</div></div><div><ul style="text-align: left;"><li><i>valideja</i>: vaatimusten on aidosti kuvattava haluttua käytettävyyttä</li><li><i>riittävän kattavia</i>: niin, että vaatimukset ottavat huomioon riittävästi erilaiset käyttäjät ja heidän erilaiset käyttötarpeensa</li><li>(tähän luetteloon yleensä kuuluva todennettavuus tuleekin täytetyksi sitä kautta, että määritetään mittarit ja mittausinstrumentit)</li></ul><div>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 <a href="https://www.youtube.com/watch?v=WJHHExdIwlU" target="_blank">tässä</a>. </div></div><div><br /></div><div>--------</div><h3 style="text-align: left;"><span style="font-family: inherit;">Vastaus Sepon alla olevaan kommenttiin </span></h3><div><span style="font-family: inherit;">(blogialusta ei antanut tehdä pitkää kommenttia, niin kirjoitan sen tähän): </span></div>
<p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;"><span style="font-family: inherit;"><br /></span></p>
<p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><span style="font-family: inherit;"><i>Seppo</i>: "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."</span></p>
<p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;"><span style="font-family: inherit;"><br /></span></p>
<p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><span style="font-family: inherit;"><i>Timo</i>: Muutama huomio tähän: </span></p>
<p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;"><span style="font-family: inherit;"><br /></span></p>
<p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><span style="font-family: inherit;">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. </span></p>
<p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;"><span style="font-family: inherit;"><br /></span></p>
<p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><span style="font-family: inherit;">"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ä. </span></p>
<p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;"><span style="font-family: inherit;"><br /></span></p>
<p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><span style="font-family: inherit;">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. </span></p>
<p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;"><span style="font-family: inherit;"> </span></p>
<p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><span style="font-family: inherit;"><i>Seppo</i>: "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."</span></p>
<p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;"><span style="font-family: inherit;"><br /></span></p>
<p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><span style="font-family: inherit;"><i>Timo</i>: 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.</span></p>
<p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><span style="font-family: inherit;"><br /><i>
Seppo</i>: "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."</span></p>
<p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;"><span style="font-family: inherit;"><br /></span></p>
<p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><span style="font-family: inherit;"><i>Timo</i>: Kylläpä näin. Ks. edellisen kohdan kommenttini. </span></p>
<p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;"><br /></p><p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><span style="font-family: inherit;"><i>
Seppo</i>: "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."</span></p>
<p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;"><span style="font-family: inherit;"><br /></span></p>
<p style="font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><span style="font-family: inherit;"><i>Timo</i>: 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. </span></p></div></div></div></div>Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com4tag:blogger.com,1999:blog-1445256629357746536.post-27456722640035059242022-01-10T10:11:00.009+02:002022-01-15T15:07:32.458+02:00Haastattelussa vuodelta 2017 kerron käytettävyyden keskeiset periaatteet tiivistettynä<p>Haastattelu "<a href="https://drive.google.com/file/d/1EHa8pr7yXuTeo26l61g4wnguLbRRj2_O/view?usp=sharing" target="_blank">Laitteiden huono käytettävyys ärsyttää</a>" 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: </p><p></p><ul style="text-align: left;"><li>käytettävyys on suunnittelijoiden vastuulla</li><li>kohdemaailma pitää olla suunnittelijoiden hallussa </li><li>käytettävyys ei perustu käyttäjien mielipiteisiin vaan suunnittelijan ammattitaitoon</li><li>käyttäjähaastatteluissa pitää keskittyä faktoihin, ei mielipiteisiin</li><li>vihje käyttäjille: älä vastaa, jos sinulta kysytään "millaisia ominaisuuksia haluat uuteen järjestelmään"</li><li>"tunne asiakkaan maailma paremmin kuin hän itse" pitäisi olla tavoite (ei ole vaikea saavuttaa!)</li><li>hankinnoissa "saa sellaista käytettävyyttä mitä tilaa"; jos ei osaa tilata, niin saa mitä sattuu</li></ul><div>Klikkaamalla kuvaa pääset lukemaan koko haastattelun. </div><p></p><div class="separator" style="clear: both; text-align: center;"><br /></div><div class="separator" style="clear: both; text-align: center;"><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://drive.google.com/file/d/1EHa8pr7yXuTeo26l61g4wnguLbRRj2_O/view?usp=sharing" style="margin-left: 1em; margin-right: 1em;" target="_blank"><img border="0" data-original-height="1753" data-original-width="1240" height="400" src="https://blogger.googleusercontent.com/img/a/AVvXsEjKKdMoL-bObKMunEg6aZllYUUzZjc04gpHdANty_0PLKu0OiGREPE_2LWkPir5I5fEZV0Ue--AA9DNPgT7FdfapFXo0caJOAcdEI5d9kiGPPPsf1eCS_9J6ts3FbOnL-_DirPy9tKkJOOLymdqVyhmZB4D4TI8ahGp-RjAD7aCNC4K-ZW62K84Jww=w283-h400" width="283" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"><br /></div><br /><div class="separator" style="clear: both; text-align: center;"><br /></div><div class="separator" style="clear: both; text-align: center;"><br /></div><div class="separator" style="clear: both; text-align: center;"><br /></div><br /><br /><div class="separator" style="clear: both; text-align: center;"><br /></div><br /><p></p>Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com0tag:blogger.com,1999:blog-1445256629357746536.post-3017318818311059422022-01-08T12:43:00.033+02:002023-03-21T08:10:30.290+02:00Kirjoitukseni Helsingin sanomissa<p>Olen kirjoitellut vuosien varrella useammankin kerran Helsingin sanomiin. Useimmat kirjoitukset käsittelivät tietojärjestelmien helppokäyttöisyyttä julkisissa hankinnoissa. </p><p>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ä...)</p><p>Lisäksi myös muutama kirjoitus Nokiasta ja yhteiskunnallisista teemoista. </p><p>Alla kokoelma kirjoituksista, osittain oman muistinikin virkistykseksi. <span style="font-family: Cambria;">Linkeistä avautuvat niin kuvankaappaukset painetusta lehdestä kuin verkossa olevat tekstit. </span><span style="font-family: Cambria;">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. </span> </p><p><b>Ammatilliset </b></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;"><span lang="EN-GB">9.11.2011: <a href="https://drive.google.com/file/d/1CiLDxJUMjKa_isx9m7SC__4LI8U5zQTd/view?usp=sharing" target="_blank">Atk-hankinnoissa vastuu kuuluu tilaajalle</a><o:p></o:p></span></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;"><span lang="EN-GB">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. </span></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;"><span lang="EN-GB"><br /></span></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;"><span lang="EN-GB">1.7.2012: <a href="https://drive.google.com/file/d/13ZrQOb2rPYz29NSQx-Shi2rIIkFyzx93/view?usp=sharing" target="_blank">Helppokäyttöisyyttä on osattava vaatia</a><o:p></o:p></span></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;"><span lang="EN-GB"></span></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;">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.)</p><div><br /></div><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;"><span lang="EN-GB">12.9.2012: <a href="https://drive.google.com/file/d/1wSAArQVVEG4PzIOwW3k4RQc5AW7qZYjN/view?usp=sharing" target="_blank">Tietojärjestelmän oltava helppokäyttöinen</a></span></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;">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. </p><div><br /></div><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;"><span lang="EN-GB">17.4.2013: <a href="https://drive.google.com/file/d/1TCZPHX2V6hlWU26mdsR7In1IVbO8ECY0/view?usp=sharing" target="_blank">Julkiset hankinnat eivät suosi halpaa</a><o:p></o:p></span></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;">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. </p><div><br /></div><div><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;"><span lang="EN-GB">18.3.2014: <a href="https://drive.google.com/file/d/1TVm2qGJ0Vu_Tfh-FOOnovyi7HUATncpd/view?usp=sharing" target="_blank">Vaikeakäyttöisyys myös uusien järjestelmien riesa</a><o:p></o:p></span></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;">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. </p></div><div><br /></div><div><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;"><span lang="EN-GB">17.10.2014: <a href="https://drive.google.com/file/d/1xjp1tPaFWl0wpE_bESeHaNQZ15BkWjHu/view?usp=sharing" target="_blank">Mistä Nokian alamäki johtui?<o:p></o:p></a></span></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;">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. </p><div><br /></div><div><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;">24.3.2015: <a href="https://drive.google.com/file/d/1euH-DzyzF7gD4dZE3UrLQf28rOQ61jSb/view?usp=sharing" target="_blank">Helppokäyttöisyyttä pitää osata vaatia</a></p></div></div><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;">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. </p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;"><br /></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;">30.8.2016: <a href="https://drive.google.com/file/d/1JPjbebLju1p1RHW7JtxAcaDGNtTEBCVs/view?usp=sharing" target="_blank">Gradun tekeminen on periaatteessa yksinkertaista</a></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;">Gradun tekemisen vaikeutta liioitellaan; gradun tekeminen on periaatteessa looginen ja yksinkertainen prosessi. Esitän gradun tekemisen kolme päävaihetta. </p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;"><br /></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;"><span lang="EN-GB">22.1.2017: <a href="https://drive.google.com/file/d/1ni3diHm7-IwM2ceugkJfAQq0s_74BoFg/view?usp=sharing" target="_blank">HSL ei tilannut helppokäyttöistä laitetta</a><o:p></o:p></span></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;">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. </p><div><br /></div><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;">18.4.2018: <a href="https://drive.google.com/file/d/1B6YMz6-GsUjjEoMdT_XJrYD6Xq6IItEG/view?usp=sharing" target="_blank">Tuliko Apotista vaikeakäyttöinen?</a></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;">Kommentoin sitä ristiriitaa, että Apotin koulutuksen kerrotaan vaativan paljon resursseja, vaikka Apotin piti olla helppokäyttöinen. </p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;"><br /></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;">1.8.2019: <a href="https://drive.google.com/file/d/1X7WUjp7Iw7EvtDeIjlHVaiT1aNl76kgp/view?usp=sharing" target="_blank">Palveluille pitää määrittää riittävä laatu</a></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;">Laatua ei saavuteta korkeammalla hankintahinnalla tai hintarajalla vaan <i>riittävän</i> laadun määrittämisellä. Tästä seuraa nurinkuriselta vaikuttava lopputulema: jos julkisissa hankinnoissa haluaa hyvää laatua, valinnan tuleekin ratkaista viime kädessä hinta.</p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;"><br /></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;"><b>Yhteiskunnalliset</b></p><div><div><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;"><span lang="EN-GB"><br /></span></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;"><span lang="EN-GB">31.10.2014: <a href="https://drive.google.com/file/d/1uMNgXsvbFg9_I2AgkCJszmwYiIpMNpiJ/view?usp=sharing" target="_blank">Avoimmuutta keskusteluun</a><o:p></o:p></span></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;">Kommentti avioliittolakikeskusteluun. </p></div><div><br /></div><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;">6.11.2014: <a href="https://drive.google.com/file/d/1wfyAKlC2sD65r6iV8L_yzvMuo1hOkN43/view?usp=sharing" target="_blank">Nykyinen avioliittolaki ei ole syrjivä</a></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;">Kommentti avioliittolakikeskusteluun. </p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;"><br /></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;"><span lang="EN-GB">4.9.2017: <a href="https://drive.google.com/file/d/15qDDOn77xIXqqwCWGkYD6byv6nJH8_1A/view?usp=sharing" target="_blank">Yhteiskunnan arvot ovat muuttuneet</a><o:p></o:p></span></p><p class="MsoNormal" style="font-family: Cambria; margin: 0cm 0cm 0.0001pt;">Kommentti Antti Rinteen "synnytystalkoisiin". </p></div><div><br /></div>Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com0tag:blogger.com,1999:blog-1445256629357746536.post-31511399537389351942020-06-15T08:53:00.028+03:002020-06-16T10:04:48.130+03:00Apotissa karmea väärinkäsitys käytettävyydestä, Oulussa ymmärretään oikein?<div><h4 style="text-align: left;"></h4><h3 style="text-align: left;">Lähtökohta</h3><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><b><br /></b></p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><b>Tämä kirjoitus on osittain hypoteesia, koska se perustuu rajattuun tietoon. </b>Apotissa kyseessä on kommentti LinkedInissä, Oulun tapauksessa uutisen otsikko. </p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><br /></p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">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.</p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><br /></p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><a href="https://www.tivi.fi/uutiset/tv/1aa4af4b-4f1f-4a59-ba97-41986860bc40?ref=newsletter:d4a7&utm_source=Tivi_Uutiskirje&utm_medium=email&utm_campaign=Tivi_Uutiskirje">Uutinen Oulussa kehitetystä Esko-potilastietojärjetelmästä</a> 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. </p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><br /></p><h3 style="text-align: left;">Taustaa</h3>
<p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><br /></p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">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ä. </p>
<p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;"><br /></p>
<p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">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 </p>
<ul>
<li style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">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). <span style="color: #e4af0a;"><a href="http://kaytettavyysnavigoija.blogspot.com/2017/03/millainen-pitaisi-olla-jarjestelmien.html">http://kaytettavyysnavigoija.blogspot.com/2017/03/millainen-pitaisi-olla-jarjestelmien.html</a> </span> </li>
<li style="color: #e4af0a; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><span style="color: #454545;">Kysytään käyttäjien mielipiteitä suunnittelun pohjaksi. <span style="color: #e4af0a;"><a href="http://kaytettavyysnavigoija.blogspot.com/2017/09/oikeaa-kayttajalahtoisyytta-ei-ole.html">http://kaytettavyysnavigoija.blogspot.com/2017/09/oikeaa-kayttajalahtoisyytta-ei-ole.html</a> </span> </span></li>
<li style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">Suunnitellaan käyttöliittymää yhdessä käyttäjien kanssa</li>
<li style="color: #e4af0a; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><span style="color: #454545;">Laitetaan tekemään asiantuntija-arviointeja <span style="color: #e4af0a;"><a href="http://kaytettavyysnavigoija.blogspot.com/2018/10/kaytettavyyden-asiantuntija-arviointi.html">http://kaytettavyysnavigoija.blogspot.com/2018/10/kaytettavyyden-asiantuntija-arviointi.html</a> </span></span></li>
<li style="color: #e4af0a; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><span style="color: #454545;">Palkataan käyttäjiä mukaan kehityshankkeseen <span style="color: #e4af0a;"><a href="http://kaytettavyysnavigoija.blogspot.com/2017/03/laakari-ottaa-esiin-kaksi-tarkeaa.html">http://kaytettavyysnavigoija.blogspot.com/2017/03/laakari-ottaa-esiin-kaksi-tarkeaa.html</a> </span> </span></li>
<li style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">käyttäjät pisteyttämään käytettävyyttä (julkisissa hankinnoissa)</li>
<li style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">jne jne</li>
</ul>
<p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;">Nämä kaikki on ”pahoja” väärinymmärryksiä käytettävyydestä ja käyttäjälähtöisyydestä. </p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;"><br /></p><h3 style="text-align: left;">Millainen oli Apotin (mahdollinen) väärinkäsitys käytettävyydestä?</h3>
<p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><br /></p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">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. </p>
<p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;"><br /></p>
<p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><b>Apotissa (mahdollisesti) valittiin käytettäyys strategiaksi, "jotta saataisiin rajatuksi muut kuin lääkärit pois hankkeen avainhenkilöistä"</b> (tämä on se kommentti LinkedInissä). </p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><br /></p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">Kun kyseessä oli potilastietojärjestelmä, niin lääkärit ovat käyttäjiä; mutta tämä ei itsessään ole oleellista.<b> </b>Pointti siis se, että käyttäjäkeskeisyys (mahdollisesti) tulkittiin tarkoittavan, että käyttäjät pitäisi olla hankkeen avainhenkilöitä. </p>
<p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;"><br /></p>
<p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><b>Siis niin väärin kuin mahdollista verrattuna aitoon käyttäjäkeskeisyyteen. </b> </p><div><b><br /></b></div>
<h3 style="text-align: left;">Miksi Apotissa (mahdollisesti) tehtiin näin? </h3>
<p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;"><br /></p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;">Syytä en tiedä. Mutta pidän täysin mahdollisena, että tällaisen väärinkäsityksen syyt ovat Apotin ulkopuolisia. </p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;"><br /></p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;">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"*. </p><div><br /></div>
<p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;">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. </p>
<p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;"><br /></p>
<p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">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. </p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><br /></p><h3 style="text-align: left;">Oulun Esko-potilastietojärjestelmän käyttäjälähtöisyys näyttää oikeaoppiselta</h3><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><font color="#454545" face="helvetica neue"><span style="font-size: 12px;"><br /></span></font></p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><font color="#454545" face="helvetica neue"><span style="font-size: 12px;">Uutisotsikko sanoo: </span></font><font color="#454545" face="helvetica neue"><span style="caret-color: rgb(69, 69, 69); font-size: 12px;">”<a href="https://www.tivi.fi/uutiset/tv/1aa4af4b-4f1f-4a59-ba97-41986860bc40?ref=newsletter:d4a7&utm_source=Tivi_Uutiskirje&utm_medium=email&utm_campaign=Tivi_Uutiskirje">Tämä porukka tuntee suomalaisen terveydenhuollon</a>”. 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ä. </span></font></p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><font color="#454545" face="helvetica neue"><span style="caret-color: rgb(69, 69, 69); font-size: 12px;"><br /></span></font></p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><font color="#454545" face="helvetica neue"><span style="caret-color: rgb(69, 69, 69); font-size: 12px;">Tietääkseni Eskon kehitystiimillä on vuosien kokemus aihealueesta. Mutta periaatteessa syvällisen perehtymisen asiakkaan maailmaan voi tehdä hyvinkin nopeasti, kuten kirjassani <a href="https://www.ketteratkirjat.fi/kirjat/36229">Kohdemaailma-analyysi</a> kerron. </span></font></p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><br /></p>
<p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;"><br /></p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;">-----------------</p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><b><br /></b></p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><b>PS. </b>Olen yrittänyt tuoda esiin perussanomaa käyttäjien oikeasta roolista jo vuosia. Myös joissakin terveydenhuollon järjestelmien seminaareissa. </p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><br /></p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">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. <b>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.</b> </p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><br /></p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><br /></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhNGeovN5L2uqe1KuArtpWnnTKIsYNJKGePWj3zG3d2r-0g7-H44pIAX0MDGfGOAtZ7707EpixhNeM5B4Lfg4js8-SA6dEXmYak_chD8T46k4n181puyjkTIiNPWmdfB8qHWH6W4kVOdy4/s800/Na%25CC%2588ytto%25CC%2588kuva+2020-6-15+kello+8.48.35.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="800" data-original-width="584" height="781" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhNGeovN5L2uqe1KuArtpWnnTKIsYNJKGePWj3zG3d2r-0g7-H44pIAX0MDGfGOAtZ7707EpixhNeM5B4Lfg4js8-SA6dEXmYak_chD8T46k4n181puyjkTIiNPWmdfB8qHWH6W4kVOdy4/w573-h781/Na%25CC%2588ytto%25CC%2588kuva+2020-6-15+kello+8.48.35.png" width="573" /></a></div><div class="separator" style="clear: both; text-align: center;"><br /></div><span><a name='more'></a></span><p style="text-align: left;"><span style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "helvetica neue"; font-size: 12px;">* Itse yritän välttää termiä "käyttäjäkeskeinen suunnittelu", koska se tosiaan voi olla harhaanjohtava. Itse puhun mieluummin "käytettävyyssuunnittelusta". Vielä tarkempi olisi "käytettävyysohjattu suunnittelu", mutta on terminä ehkä vähän kömpelöhkö.</span></p><p style="color: #454545; font-family: "helvetica neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;"><br /></p></div><div><br /></div>Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com1tag:blogger.com,1999:blog-1445256629357746536.post-38402437107420978662020-05-25T12:10:00.000+03:002020-05-27T08:53:14.882+03:00Apotin kaksi virhettä: Vastine saamiini palautteesiin<b>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</b><b>äytettävyyden onnistumisen arviointiin tämän tasoiset tiedot eivät kuitenkaan riitä. </b><b>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. </b><br />
<br />
Sain aika paljon palautetta edellisestä <a href="http://kaytettavyysnavigoija.blogspot.com/2020/05/apotin-hankinnassa-tehtiin-kaksi-vanhaa.html" target="_blank">Apotti-kirjoituksestani</a>. Erityisesti sain kommentteja <a href="https://www.linkedin.com/feed/update/urn%3Ali%3Aactivity%3A6666559493180051457/?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6666559493180051457%2C6670024981415526400%29&midToken=AQGwsPzRzRfKsw&trk=eml-email_notification_single_commented_on_your_update_01-notifications-1-hero%7Ecard%7Efeed&trkEmail=eml-email_notification_single_commented_on_your_update_01-notifications-1-hero%7Ecard%7Efeed-null-21jhl%7Ekajz2cam%7Eeg-null-voyagerOffline">LinkedInissä</a>. Sain myös suoraa palautetta Apotilta. <br />
<br />
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.<br />
<br />
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 <a href="https://kaytettavyysnavigoija.blogspot.com/2016/11/massiivia-kaytettavyystesteja-ja.html" target="_blank">moniosaisen analyysin</a>.<br />
<br />
Aukaisen seuraavassa tarkemmin näitä kohtia (saamani palautteet kirjoitettu <i>kursiivilla</i>).<br />
<br />
<b>1. Rakenteisuus</b><br />
<div>
Aloitetaan positiivisella asialla: </div>
<div>
<br />
<i>”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".</i><br />
<br />
Rakenteisuus kuulostaan erinomaisen hyvältä! <br />
<br />
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”). <br />
<br />
Jos Apotti on onnistunut rakentamaan käytettävyydeltään hyvän rakenteisuuden, niin hienoa! </div>
<div>
<br />
<b>2. "Käytettävyydeltään paras"</b></div>
<div>
<i>”Käytettävyydeltään epic oli selkeästi paras tarjolla olleista”.</i></div>
<div>
<br /></div>
<div>
Jotta voidaan arvioida sen väitteen paikkaansa pitävyyttä, että epic oli ”käytettävyydeltään paras”, niin pitäisi tietää <br />
<ol>
<li>mitkä olivat käytetyt käytettävyysmittarit </li>
<li>miten nämä mittarit olivat määritetyt </li>
</ol>
Mittarien pitää siis olla validit (mitataan oikeita asioita) ja riittävän kattavat (että mittauksissa ei jää huomioimatta oleellisia osa-alueita järjestelmästä). </div>
<div>
<br /></div>
<div>
Ydinkysymys on: mitä olivat mittarit, ja miten ne oli johdettu?<br />
<br />
<b>3. Arvioinnin tekijät </b></div>
<div>
<i><br /></i></div>
<div>
<i>"Arvioinnin tekijät olivat käyttäjät ja ennen kaikkea käytettävyyden arvioinnin ammattilaiset”. </i></div>
<div>
<br /></div>
<div>
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ä. </div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
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ä.<br />
<br />
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.<br />
<br />
Myöskin käytettävyysammattilaisten tuotosten laadussa on vaihtelua. Tätä on tutkittu ns. CUE-tutkimuksissa, joista kirjoitin <a href="https://kaytettavyysnavigoija.blogspot.com/2011/04/kaytettavyyden-varmistus-ei-ole.html" target="_blank">täällä</a>. </div>
<div>
<br /></div>
<div>
<b>4. Käytettävyysvaatimukset</b></div>
<div>
<br />
<i>”Käytettävyydelle oli vaatimukset, ja ne jotka eivät läpäisseet, eivät päässeet kilpailutuksessa jatkoon". </i><br />
<br />
Jotta käytettävyysvaatimusten validiteettia voisi arvioida, tässä pitäisi tietää, mitä nämä vaatimukset konkreettisesti olivat. Tarkemmin, pitäisi tietää:</div>
<div>
<ul>
<li>Käytetytyt mittarit, ja miten ne on johdettu (kuten kohdassa 2) </li>
<li>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.</li>
</ul>
<div>
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.<br />
<br />
Ydinkysymys jatkuu: Mitä olivat mittarit, tavoitetasot ja niiden perusteet?</div>
<div>
<br /></div>
<b>5. Parhaan valikoituminen</b></div>
<div>
<i>"Valikoitui se, joka oli käytettävyydeltään paras". </i><br />
<br />
Kaksi näkökulmaa tähän: </div>
<div>
<ul>
<li>Ei voida tietää valikoituiko käytettävyydeltään paras, ellei tiedä mittareita ja niiden validitettia (ks. edelliset kohdat)</li>
<li>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ä) </li>
</ul>
<div>
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. </div>
<div>
<br /></div>
<b>6. Järjestelmän rakentamisesta</b><br />
<i>"Itse järjestelmän rakennuksessa käyttäjät rakensivat lääke- ja hoitotieteellisen sisällön". </i></div>
<div>
<br />
Tämäkin on sanottu sen verran yleisellä tasolla, että vaikea ottaa suoraan kantaa. Mutta yleisesti ottaen, <b>käyttäjien ei pitäisi rakentaa mitään</b>. Maailma on täynnä esimerkkejä, miten tämä tietää epäonnistumista. </div>
<div>
<br />
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 <a href="http://kaytettavyysnavigoija.blogspot.com/2020/05/apotin-hankinnassa-tehtiin-kaksi-vanhaa.html" target="_blank">edellisessä kirjoituksessani</a>, sellaisen ymmärryksen hankkiminen ei ole ollenkaan kohtuuton tehtävä. (Itse olen kirjoittanut aiheesta enemmän <a href="https://www.ketteratkirjat.fi/kirjat/36229" target="_blank">Kohdemaailma-analyysi -kirjassa</a>).<br />
<br />
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ä <b>ei koskaan pitäisi vastuuttaa käyttäjiä.</b> </div>
<div>
<br /></div>
<div>
Miten käyttäjät ottaa mukaan tietojärjestelmäkehitykseen, ja miten ei, olen kirjoittanut eduskunnan tulevaisuusvalikunnan julkaisussa <a href="https://www.eduskunta.fi/FI/naineduskuntatoimii/julkaisut/Documents/tuvj_12+2014.pdf" target="_blank">Silmät auki IT-etiikkaan</a>. </div>
Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com1tag:blogger.com,1999:blog-1445256629357746536.post-62360944641167819442020-05-11T08:37:00.000+03:002020-05-18T22:01:09.740+03:00Apotin hankinnassa tehtiin kaksi vanhaa perusvirhettä<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
Pääkaupunkiseudun potilasitietojärjestelmän Apotin käytettävyys näyttää todella pettävän. Tässä muutama uutisjuttu asiasta huhtikuulta: </div>
<div class="" style="font-stretch: normal; line-height: normal; margin: 0px;">
<ul>
<li><span style="color: #454545; font-family: "helvetica neue"; font-size: x-small;"><span style="caret-color: rgb(69, 69, 69);"><a href="https://www.tivi.fi/uutiset/tv/e1c672b4-bb74-4b6d-a300-26e0b2062744?ref=newsletter:a291&utm_source=Tivi_Uutiskirje_ilta&utm_medium=email&utm_campaign=Tivi_Uutiskirje_ilta" target="_blank">It-järjestelmän käyttäjät antoivat tylyjä arvosanoja – Vantaa muutti mieltään käyttöönoton “onnistumisesta”</a></span></span></li>
</ul>
<ul>
<li><span style="color: #454545; font-family: "helvetica neue"; font-size: x-small;"><a href="https://www.hs.fi/kaupunki/art-2000006462316.html" target="_blank">Apotti aiheuttaa yhä niin paljon virhetilanteita sairaaloissa, että osa lääkäreistä toivoo vanhoja järjestelmiä takaisin koronakriisin ajaksi</a></span></li>
</ul>
<ul>
<li><a href="https://www.tivi.fi/uutiset/tv/5ed45be4-c34f-4583-a2d3-af85b4feef6d?ref=newsletter:d77d&utm_source=Tivi_Uutiskirje&utm_medium=email&utm_campaign=Tivi_Uutiskirje" target="_blank"><span style="font-size: x-small;">Espoo hylkää sittenkin Apotin – ”Käyttäjäkokemus on ollut murskaavaa, harvoin näkee näin huonoja arvioita”</span></a></li>
</ul>
</div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
Apotin käytettävyysongelmia tuovat esiin myös professorit <a href="https://www.hs.fi/kaupunki/art-2000006463034.html" target="_blank">Antti Oulasvirta ja Johanna Kaipio</a>. Oulasvirta pitää ”monimutkaisia valikoita, välilehtiä ja lisäikkunoita kömpelöinä”. </div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;">
<br class="" /></div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
Vaikka Apotin eteen tehtiin paljon käytettävyystyötä, sen vaikeakäyttöisyys oli ennakoitavissa jo sen perusteella, miten hankinta tehtiin. </div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
<br /></div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
<b>Tehtiin kaksi päävirhettä.</b></div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;">
<br /></div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
<b>Virhe 1:</b> <i>Käytettävyys oli tarjouspyynnössä vertailutekijä eikä pakollinen vaatimus</i>. Tämän <a href="https://www.hs.fi/kaupunki/art-2000006463034.html" target="_blank">toteaa</a> 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ä. </div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;">
<br class="" /></div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
<i>Oikea ratkaisu olisi ollut, että käytettävyys olisi ollut tarjouspyynnössä pakollinen vaatimus. </i>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. </div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;">
<br class="" /></div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
<b>Virhe 2</b>: <i>Käyttäjät otettiin mukaan väärällä tavalla hankinnassa.</i> 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. </div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;">
<br class="" /></div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
<i>Oikea ratkaisu olisi siis ollut se, että Apotin käyttöliittymän suunnittelusta olisivat vastanneet yksiselitteisesti suunnittelun ammattilaiset.</i> 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ä. </div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;">
<br class="" /></div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
<b>Itse yritin</b> vaikuttaa Apotin käytettävyyskäytäntöihin sekä julkisesti - esimerkiksi vieraskynäkirjoitus (<a href="http://kaytettavyysnavigoija.blogspot.com/2012/07/timon-vieraskyna-hs-172012-osattava.html" target="_blank">HS 2.7.2012</a>) - 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. </div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;">
<br class="" /></div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
<b>Oikeiden toimintatapojen haasteet</b></div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
<br /></div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
Jotta julkisten tietojärjestelmien hankinnoissa päästäisiin hyvään käytettävyyteen, <i>tarvitaan siis kaksi perusmuutosta nykyisiin käytäntöihin</i>: </div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
<ul>
<li>käytettävyys tarjouspyynnön pakolliseksi vaatimukseksi ja </li>
<li>käyttäjien ja suunnittelijoiden roolituksen muuttaminen</li>
</ul>
</div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
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. </div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;">
<br class="" /></div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
Sen sijaan suunnittelijoiden on mahdollista saada <a href="https://www.ketteratkirjat.fi/kirjat/36229" target="_blank">kohtuu ponnistuksin syvällinen ymmärrys</a> 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. </div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;">
<br class="" /></div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;">
<b>Mikä julkinen taho olisi edelläkävijä?</b></div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px; min-height: 14px;">
<br /></div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
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?</div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
<br /></div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
-----</div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
(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)<br />
<br />
Edit 18.5.2020. Tarkensin juttua Johanna Kaipion kommentin perusteella. Pahoittelen epätarkkuuksia. </div>
<div class="" style="caret-color: rgb(69, 69, 69); color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; margin: 0px;">
<br /></div>
Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com1tag:blogger.com,1999:blog-1445256629357746536.post-72476246476828509362019-09-19T13:28:00.000+03:002019-09-20T08:55:32.064+03:00Miten toimia käytettävyysasiantuntijana eettisesti oikein?<i>Käytettävyysasiantuntijana olen törmännyt tilanteisiin, jossa asiakas edellyttää vääriä toimenpiteitä. Miten toimia eettisesti oikein?</i><br />
<i><br /></i>
<b> Tapaus muutaman vuoden takaa</b><br />
<b><br /></b>
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ää <i>riittävän käytettävyyden</i> <i>kriteerit pakollisina vaatimuksina. </i><br />
<br />
(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ä, <a href="https://kaytettavyysnavigoija.blogspot.com/2019/08/palveluille-pitaa-maarittaa-riittava.html" target="_blank">viimeksi edellisessä blogikirjoituksessani/ Helsingin sanomissa 1.8.2019.</a>).<br />
<br />
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. <br />
<br />
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ä.<br />
<br />
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 <a href="https://uxpa.org/uxpa-code-of-professional-conduct/">Code of Professional Conduct</a> -ohjeella, ja esimerkiksi ohjeen kohdalla ”Be Honest with Everyone”. <br />
<br />
Esimies ymmärsi näkökulmani, mutta näki, että pitää kuitenkin tehdä, niin kuin vastuuhenkilö näkee. <br />
<br />
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. <br />
<br />
<b>Toinen tapaus</b><br />
<b><br /></b>
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.<br />
<br />
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. <br />
<br />
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ä?<br />
<br />
<br />
PS. Muutama vuosi sitten Eduskunnan tulevaisuusvaliokunta julkaisi kirjan <a href="https://www.eduskunta.fi/FI/tietoaeduskunnasta/julkaisut/Documents/tuvj_12+2014.pdf" target="_blank">Silmät auki IT-etiikkaan</a>. Kirjan yksi kappale on kirjoittamani, ja siinä kerron käytettävyyssuunnittelun etiikasta laajemmin, menetelmäkohtaisesti.Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com0tag:blogger.com,1999:blog-1445256629357746536.post-68745083619858700192019-08-06T15:30:00.004+03:002022-03-14T09:01:38.804+02:00Ratkaisu julkisten hankintojen laatuongelmiiin: pitää määrittää "riittävä laatu"Huomasin Hesarissa mielipidekirjoituksia julkisista hankinnoista, ja erityisesti niiden ongelmallisesta laadusta.<br />
<br />
Kun kirjoitukset eivät mielestäni menneet asian ytimeen, niin kirjoitin, mistä asia kiikastaa. Eli siitä, että hankkijat eivät määritä tarjouspyyntöön hankittavalle palvelulle (järjestelmälle) <em>riittävää laatua</em>. Käytettävyyden suhteen se tarkoittaa, että ei määritetä (oikealla tavalla) <i>riittävää käytettävyyttä/ käyttökokemusta</i>.<br />
<br />
Jos tarjouspyynnössä vaadita riittävää laatua, sitä mitä todennäköisimmin ei myöskään saada.<br />
<br />
Kirjoitukseni, julkaistu 1.8.2019, näkyy <a data-cke-saved-href="https://www.hs.fi/paivanlehti/01082019/art-2000006190447.html" href="https://drive.google.com/file/d/1X7WUjp7Iw7EvtDeIjlHVaiT1aNl76kgp/view?usp=sharing" target="_blank">tästä linkistä</a>. Kirjoitus on kopioitu myös alle.<br />
<br />
PS. Olen kirjoittanut tähän asiaan liittyen Hesariin ensimmäisen kerran vuonna 2011. Ja myös moniin muihin foorumeihin. Kukaan ei ole kumonnut näkemystäni, mutta käytäntöjen muuttamiseen ei tunnu olevan innostusta. Ehkä syynä se, että kenelläkään (hankkijalla) ei lopulta ole motivaatiota...?<br />
<br />
PPS. Jos luet kirjoitusta käytettävyysnäkökulma mielessä, niin korvaa sana "laatu" sanalla "käytettävyys".<br />
<br />
-----------------<br />
<br />
<div style="color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal;">
<h3>
Palveluille pitää määrittää riittävä laatu</h3>
</div>
<div style="color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; min-height: 14px;">
<i><br /></i>
<i>Julkiset hankinnat tarvitsevat uutta ajattelua. </i></div>
<div style="color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; min-height: 14px;">
<br /></div>
<div style="color: #454545; font-family: "helvetica neue"; font-stretch: normal; line-height: normal;">
<span style="font-size: xx-small;">Helsingin sanomat 1.8.2019</span></div>
<div style="color: #454545; font-family: "helvetica neue"; font-stretch: normal; line-height: normal; min-height: 14px;">
<br /></div>
<div style="color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal;">
MIELIPIDESIVUILLA on kirjoitettu julkisten hankintojen laadusta. Toimitusjohtaja Ilpo Niemen mukaan (<a href="https://www.hs.fi/paivanlehti/28072019/art-2000006186681.html"><span style="color: #e4af0a;">HS 28.7.</span></a>) parempi laatu ja korkeampi hinta voivat lopulta tulla hankkijalle edullisemmaksi kuin halvimman tarjouksen hyväksyminen. Hankintajohtaja Timo Martelius ehdotti (<a href="https://www.hs.fi/paivanlehti/30072019/art-2000006188303.html"><span style="color: #e4af0a;">HS 30.7.</span></a>) yhtenä ratkaisuna käänteistä kilpailutusta: hankintayksikkö ilmoittaa hinnan, jonka on valmis maksamaan palvelusta, ja kilpailu käydään vain laatuun liittyvillä perusteilla.</div>
<div style="color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; min-height: 14px;">
<br /></div>
<div style="color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal;">
Kumpikaan näistä kirjoituksista ei kuitenkaan anna konkreettista ratkaisua hankintojen yleiseen ja perimmäiseen ongelmaan: miten varmistaa hankinnan riittävän hyvä laatu? Korkeampi hinta tai tietty hintaraja ei takaa laatua. Ratkaisu on riittävän laadun määrittäminen hankittavalle palvelulle.</div>
<div style="color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; min-height: 14px;">
<br /></div>
<div style="color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal;">
Riittävä laatu tarkoittaa laadun vähimmäistasoa, jolla palvelu toimii riittävän hyvin käyttötarkoituksessaan. Riittävä laatu täyttää liiketoiminnan, asiakkaiden, käyttäjien ynnä muiden tarpeet.</div>
<div style="color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; min-height: 14px;">
<br /></div>
<div style="color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal;">
Jos palvelun laatu on alle vähimmäistason, seurauksena on ongelmia, käyttäjien tyytymättömyyttä, lisäkustannuksia ja niin edelleen. ”Ylilaadusta” taas ei kannata maksaa, koska se ei tuo palveluun merkittävää lisäarvoa.</div>
<div style="color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; min-height: 14px;">
<br /></div>
<div style="color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal;">
Haaste on, että jokaiselle hankinnalle pitää määrittää omat riittävän laadun mittarit ja kriteerit, eikä se yleensä ole helppoa. Riittävään laatuun liittyvä ajattelu on kuitenkin välttämätöntä hankintojen laadun kehittämiseksi. Vaikka lähestymistavassa on haasteensa, se vapauttaa resursseja yleisesti käytetyltä laatutekijöiden vertailulta, joka on tarpeetonta, hankalaa ja raskasta eikä lopulta takaa laatua.</div>
<div style="color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; min-height: 14px;">
<br /></div>
<div style="color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal;">
Tarjouspyynnössä riittävä laatu näkyy sitten pienenä yllätyksenä. Kun riittävä laatu on pakollisena vaatimuksena ja kun laatuvertailuja ei tarvita, ainoaksi valintakriteeriksi jää hinta. Lopputulema kuulostaa nurinkuriselta. Jos julkisissa hankinnoissa haluaa hyvää laatua, valinnan tuleekin ratkaista viime kädessä hinta.</div>
<div style="color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; min-height: 14px;">
<br /></div>
<div style="color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal;">
Timo Jokela</div>
<br />
<div style="color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal;">
filosofian tohtori, dosentti, Helsinki</div>
Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com0tag:blogger.com,1999:blog-1445256629357746536.post-80437753299603684332019-07-31T12:45:00.000+03:002019-07-31T12:45:11.161+03:00Matkakortinlukijan uusi versio: onko käytettävyysongelmat ratkaistu?Vuosien 2016 - 2017 vaiheessa julkaisin moniosaisen analyysin silloin uudesta pääkaupunkiseudun paikallisliikenteen matkakortinlukijasta. Raportoin ongelmista niin lukijan käytettävyydessä kuin hankintatavassa.<br />
<br />
Keväällä 2019 matkakortinlukijasta tuli uusi versio uusien matkustusvyöhykkeiden myötä. Paraniko käytettävyysongelmat uuden version myötä? Katso video alta (pituus: 3 min 32 sek).<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/BLHP20q0McI/0.jpg" src="https://www.youtube.com/embed/BLHP20q0McI?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com1tag:blogger.com,1999:blog-1445256629357746536.post-75432331298393373432019-05-02T10:42:00.002+03:002019-05-06T21:05:54.203+03:00MIllainen on UX -strategia?<span style="background-color: white; color: #333333; font-family: "libre franklin" , "helvetica neue" , "helvetica" , "arial" , sans-serif; font-size: 16px;">Vaikka UX -strategiaa pidetään tärkeänä, konkreettiset esimerkit puuttuvat. </span><br />
<br />
<span style="background-color: white; color: #333333; font-family: "libre franklin" , "helvetica neue" , "helvetica" , "arial" , sans-serif; font-size: 16px;">Jotta saataisiin konkreettisia esimerkkejä, UXPA Boston järjesti "<a href="http://strat.uxpaboston.org/" target="_blank">UX Strategy</a>" -kilpailun osana </span><span style="background-color: white; color: #333333; font-family: "libre franklin" , "helvetica neue" , "helvetica" , "arial" , sans-serif; font-size: 16px;">2019 UXPA Boston -konferenssia. Tanskalaisen UX-konsultin Rolf Molichin toimisto </span><span style="background-color: white; color: #333333; font-family: "libre franklin" , "helvetica neue" , "helvetica" , "arial" , sans-serif; font-size: 16px;">DialogDesign sponsoroi 3000 dollarin palkinnon jaettavaksi parhaille ehdotuksille. </span><br />
<span style="background-color: white; color: #333333; font-family: "libre franklin" , "helvetica neue" , "helvetica" , "arial" , sans-serif; font-size: 16px;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<img border="0" data-original-height="449" data-original-width="809" height="221" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhhGiyXNjZ9OpEjT-HsYmY22_6-m7CdzyLB19OAHFANgz2YVBmf1n1uqqkUIIaGpstz518BbOJuKbZfOEkKeuqdKJI0EVHqwTRPuYM2mABGhdMQm2ku1y0Snr8nw8A34EJUkY3b8lZd-YA/s400/Na%25CC%2588ytto%25CC%2588kuva+2019-5-2+kello+10.41.39.png" width="400" /><span id="goog_1389021579"></span><span id="goog_1389021580"></span><a href="https://www.blogger.com/"></a></div>
<div style="text-align: center;">
<br /></div>
<span style="background-color: white; color: #333333; font-family: "libre franklin" , "helvetica neue" , "helvetica" , "arial" , sans-serif; font-size: 16px;">Kilpailussa jaettiin viisi palkintoa. Parhaan (1000 dollaria) sai Ann Thompsonin ehdotus. Neljä ehdotusta palkittiin "toisella" sijalla (500 dollaria) ja itse pääsin tähän joukkoon. </span><br />
<span style="background-color: white; color: #333333; font-family: "libre franklin" , "helvetica neue" , "helvetica" , "arial" , sans-serif; font-size: 16px;"><br /></span><span style="background-color: white; color: #333333; font-family: "libre franklin" , "helvetica neue" , "helvetica" , "arial" , sans-serif; font-size: 16px;">Oma ehdotukseni arvioitiin seuraavasti: "<i>I</i></span><span style="background-color: white; color: #333333; font-family: "libre franklin" , "helvetica neue" , "helvetica" , "arial" , sans-serif; font-size: 16px;"><i>t challenges assumptions about how we typically strategize. It differs from the other submissions in a thought-provoking way</i>". </span><span style="background-color: white; color: #333333; font-family: "libre franklin" , "helvetica neue" , "helvetica" , "arial" , sans-serif; font-size: 16px;">En pidä arviotani yllättävänä - sen verran usein olen huomannut olevani "toisinajattelija" omalla alallani. </span><br />
<span style="background-color: white; color: #333333; font-family: "libre franklin" , "helvetica neue" , "helvetica" , "arial" , sans-serif; font-size: 16px;"><br /></span>
<span style="background-color: white; color: #333333; font-family: "libre franklin" , "helvetica neue" , "helvetica" , "arial" , sans-serif; font-size: 16px;">Tietoa kilpailusta ja palkittujen UX-strategiaehdotukset löytyvät <a href="http://strat.uxpaboston.org/" target="_blank">täältä</a>. </span><br />
<div style="text-align: center;">
<br /></div>
<br />Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com1tag:blogger.com,1999:blog-1445256629357746536.post-73766681220507135482019-03-15T12:34:00.003+02:002019-03-15T13:29:05.131+02:00Millainen on onnistunut julkinen hankinta? Perusasiat<b><i>Julkisen hankinnan tavoite on hieno: asettaa tarjoajat samalla viivalle. Julkisen hankinnan osaamisen tärkein kriteeri on se, miten määrittää riittävä laatu tarjouspyyntöön. Tämä usein ymmärretään väärin ja tässä usein epäonnistutaan. </i></b><br />
<br />
<br />
Julkisen hankinnan ongelmat ovat nousseet viimeksi esiin, kun tuli ilmi yksityisten toimijoiden laiminlyönnit vanhusten hoidossa. Ja monet ovat moittineet julkista hankintaa, ja esittäneet erilaisia "parempia" tapoja, miten hankinnat pitäisi hoitaa.<br />
<br />
Valitettavasti monilla kommentaattoreilla ei näytä olevan edes perusymmärrystä julkisen hankinnan perussäännöistä.<br />
<br />
Seuraavassa yritän vetää yhteen julkisen hankinnan oleellisimmat piirteet. Tarkoitukseni on, että asiaan perehtymätönkin lukija saisi peruskäsityksen siitä, mistä julkisissa hankinnoissa on kyse.<br />
<br />
Myös aiemmin olen kirjoitellut ja tehnyt videoita asiasta, esim.<br />
<br />
<ul>
<li><a href="http://kaytettavyysnavigoija.blogspot.com/2017/04/miksi-julkinen-taho-hankkii-jatkuvasti.html">"Miksi julkinen taho hankkii hankalakäyttöisiä tie...</a></li>
<li><a href="http://kaytettavyysnavigoija.blogspot.com/2017/09/miten-hankkia-helppokayttoisia.html">Miten hankkia helppokäyttöisiä tietojärjestelmiä? ...</a></li>
<li><a href="http://kaytettavyysnavigoija.blogspot.com/2016/11/massiivia-kaytettavyystesteja-ja.html">Matkakortinlukija. Osa 1: Massiivia käytettävyyste...</a> (moniosainen analyysi pääkaupunkiseudun matkakortinlukijan hankinnasta ja käytettävyysongelmista)</li>
</ul>
<br />
<h3>
Julkisten hankintojen tavoite on hieno</h3>
Julkisten hankintojen käytännöillä on hieno tavoite: varmistaa se, että julkinen taho on puolueeton, että kaikki tarjoajat ovat samalla viivalla.<br />
<br />
Siis että vältettäisiin tuttujen ja tiettyjen yritysten suosimista. Ja että tehtäisiin mahdolliseksi, että myös uusilla yrityksillä on mahdollisuus päästä tasapuolisesti mukaan julkisen tahon toimittajaksi.<br />
<br />
Julkisia hankintoja ja sen käytäntöjä ei siis pidä itsessään arvostella. Sen sijaan voi arvostella sitä, miten julkiset hankinnat käytännössä toteutetaan. Julkisen hankinnan laadukas toteuttaminen ei ole helppoa, ja hankinnat tehdään usein kyseenalaisella laadulla.<br />
<br />
<h3>
Tarjouspyyntö on julkisen hankinnan keskeisin asia</h3>
<div>
<i>Julkisten hankintojen keskeisin dokumentti on tarjouspyyntö. </i>Tarjouspyynnön perusteella</div>
<div>
<ul>
<li>tarjoajat laativat tarjouksensa sisällön, ts. mitä sitoutuvat toimittamaan asiakkaalle</li>
<li>valitaan voittava tarjous</li>
</ul>
</div>
<div>
Tarjouspyyntö sisältää kolme keskeistä asiaa: </div>
<div>
<ol>
<li><b>Kelpoisuusvaatimukset. </b>Tarkoittaa vaatimuksia, mitkä asetetaan <i>tarjoavalle yritykselle</i>. Esimerkiksi jos hankittava tuote tai palvelu on sisällöltään "iso", voidaan vaatia, että tarjoava yritys on vähintään tietyn kokoinen. Tai voidaan vaatia, että tarjoavalla yrityksellä on aiempaa kokemusta samantyyppisten tuotteiden/ palvelujen toimittamisesta. </li>
<li><b>Laatuvaatimukset</b> (käytetään usein nimitystä "pakolliset vaatimukset"). Tarkoittaa vaatimuksia, mitkä asetetaan <i>tarjotulle tuotteelle tai palvelulle</i>. Jos hankitaan vanhusten hoivapalvelua, niin pakolliseksi resurssivaatimukseksi voitaisiin asettaa "0,7", eli 7 hoitohenkilökunnan jäsentä 10 vanhusta kohden. </li>
<li><b>Vertailukriteerit. </b>Määrittää <i>mittarit, joiden perusteella valitaan voittaja</i> niiden tarjousten joukosta, jotka täyttävät sekä kelpoisuusvaatimukset että pakolliset vaatimukset. Vertailukriteereissä yksi tekijä on aina hinta; lisäksi voi olla laatukriteereitä. Esimerkiksi hinnan painoarvo voi olla 70%, laatutekijä a 20%, laatutekijä b 5% ja laatutekijä c 5%. <i>Voittaja on se, joka saa eniten pisteitä, </i>kun eri valintakriteerien pisteet lasketaan painotetusti yhteen. </li>
</ol>
Huomioitavaa on siis se, että </div>
<div>
<ul>
<li>laatuvaatimukset määrittävät, millainen tuote tai palvelu tilataan</li>
<li>voittavaa tarjousta ei valita "älyllisesti", vaan voittaja määritetään mekaanisesti laskemalla vertailukriteerien pisteitä yhteen</li>
<li>ja siis se, että tarjouspyynnön sisältö - miten kelpoisuusvaatimukset, laatuvaatimukset ja vertailukriteerit on laadittu - "ratkaisee kaiken"</li>
</ul>
<br />
<ul>
</ul>
<ul>
</ul>
<h4>
Käytännön huomiot osoittavat, että tarjouspyyntöjä ei useinkaan osata tehdä oikein</h4>
</div>
<div>
Julkisen hankinnan onnistumisen ratkaisee siis se, miten tarjouspyyntö on laadittu. </div>
<div>
<br /></div>
<div>
Itse olen seurannut tietojärjestelmien hankintoja, ja huomannut, että tarjouspyynnöissä on paljon ongelmia. Esimerkiksi en ole nähnyt ensimmäistäkään tarjouspyyntöä - ja olen käynyt niitä läpi ehkä 200 - jossa tietojärjestelmän <i>käytettävyys</i> (helppokäyttöisyys) olisi osattu laittaa tarjouspyyntöön oikealla tavalla (= että varmistettaisiin, että järjestelmän käytettävyys on <i>riittävän hyvä</i>). </div>
<div>
<br /></div>
<div>
Oletukseni on, että myös muiden kuin tietojärjestelmien tarjouspyynnöissä on ongelmia. Jos ei olisi, niin <i>ei pitäisi olla myöskään ongelmia tarjotuissa palveluissa, kuten vanhusten huollossa</i>. </div>
<div>
<br /></div>
<div>
<i>Mahdollisia ongelmia voi olla kaikissa katergorioissa (</i>kelpoisuusvaatimuksissa, laatuvaatimuksissa ja vertailukriteereissä)<i>, </i>esimerkiksi</div>
<div>
<ul>
<li>määritetään kelpoisuusvaatimuksia, jotka turhaan sulkevat pois joitakin yrityksiä</li>
<li>asetetaan laatuvaatimuksia, jotka ovat tarpeettomia ja tekevät toimittajien ratkaisuista turhan monimutkaisia, laaduttomia ja kalliita</li>
<li>jätetään oleellisia laatuvaatimuksia asetettamatta</li>
<li>vertailukriteerit asetetaan väärin </li>
</ul>
<br />
<ul>
</ul>
<div>
<div>
<h4>
Suuri väärinkäsitys laadun ja hinnan suhteessa</h4>
</div>
</div>
</div>
<div>
Ehkä merkittävin virhe ja väärinkäsitys, mikä tarjouspyynnöissä tehdään, on <i>miten hinta ja laatu sisällytetään niihin. </i> </div>
<div>
<br /></div>
<div>
Ajatellaan, että jos vertailukriteereissä hinnan painoarvo asetetaan pieneksi (esim. 30%) ja laatutekijöiden painoarvo suureksi (esim 70%), niin saataisiin hyvää laatua. <i>Tämä on täydellinen väärinkäsitys. </i>Näin ei varmisteta laatua. </div>
<div>
<i><br /></i></div>
<div>
Oikea tapa on määrittää <i>riittävä laatu </i>pakollisiin vaatimuksiin, ja <i>asettaa vertailukriteereiksi pelkästään hinta</i> (vertailukriteereissä hinnan painoarvo on 100%)<i>. Näin saadaan riittävän hyvä tuote tai palvelu edullimmalla hinnalla. </i></div>
<div>
<br /></div>
<div>
Haasteena on sitten tietenkin usein se, mikä on riittävä laatu ja miten se määrittää. <i>Tämän määritys onkin julkisen hankinnan aidon osaamisen mittari. </i></div>
Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com0tag:blogger.com,1999:blog-1445256629357746536.post-17259931041281387522019-01-14T11:08:00.003+02:002019-01-14T11:09:10.841+02:00Uusi kirja julkaistu: "Kohdemaailma-analyysi. Syvälliseen asiakasymmärrykseen heti kehityshankkeen alussa". Uusi kirjani "<i>Kohdemaailma-analyysi. Syvälliseen asiakasymmärrykseen heti kehityshankkeen alussa</i>" julkaistiin 11.1.2019.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhWDulR7wbfxIBPcUug8WDpVtZPIr4D-Km2YW4Pk09NNpmZqcMZ8iNlTRMXCDPviwms7zdHUjo2H2BlqQNCOq3l3_7HXzl_V3J3tlL3ic_iGaC7tcLxWBOBRDu33N9ACE0l4qPLpA12sg4/s1600/IMG_0594.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="1600" data-original-width="1200" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhWDulR7wbfxIBPcUug8WDpVtZPIr4D-Km2YW4Pk09NNpmZqcMZ8iNlTRMXCDPviwms7zdHUjo2H2BlqQNCOq3l3_7HXzl_V3J3tlL3ic_iGaC7tcLxWBOBRDu33N9ACE0l4qPLpA12sg4/s320/IMG_0594.jpg" width="240" /></a>Kirjan sisällön voi tiivistää erään palautteen sanoin: <i>”Aivan ehdoton tapa aloittaa joku projekti, jotta voi varmistua, että kaikki puhuu jatkossa samaa kieltä ja ymmärtää asiat samalla tavalla.”</i><br />
<br />
Enemmän kirjasta:<br />
<br />
<ul>
<li><a href="https://www.youtube.com/watch?v=Y0RUGQjo7G8&feature=youtu.be" target="_blank">esittelytilaisuuden videotallenne</a></li>
<li><a href="https://kaytettavyysnavigoija.blogspot.com/2019/01/askel-aitoon-asiakasymmarrykseen.html" target="_blank">aiempi blogikirjoitukseni</a></li>
<li>kustantajan <a href="https://www.ketteratkirjat.fi/kirjat/36229" target="_blank">Ketterät kirjat</a> sivulta, josta kirjan voi myös tilata. </li>
</ul>
<br />
<br />
<br />
<div style="caret-color: rgb(114, 114, 114); color: #727272; font-family: "Open Sans"; font-size: 15px; padding: 0.5em 0px;">
<br /></div>
<div style="caret-color: rgb(114, 114, 114); color: #727272; font-family: "Open Sans"; font-size: 15px; padding: 0.5em 0px;">
<br /></div>
Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com0tag:blogger.com,1999:blog-1445256629357746536.post-63232315461641345242019-01-01T19:44:00.000+02:002019-01-01T19:47:49.150+02:00Kohtele asiakasta samoin kuin käytettävyystestauksessa kohdellaan käyttäjää<b>Kohdemaailma-analyysi on menetelmä, jolla pääset nopeasti syvälliseen asiakasymmärrykseen heti kehityshankkeen alussa. Menetelmä ja <i>siitä kertova kirja</i> julkaistaan webinaarissa<i> perjantaina 11.1.2019 klo 13. </i></b><br />
<b><br /></b>
<b>Webinaarin ilmoittautumissivulle pääset <a href="https://www.ketteratkirjat.fi/kirjat/36229" target="_blank">tästä</a> (paikkoja rajoitetusti). </b><br />
<br />
-----------------------------<br />
Seuraavassa johdatusta Kohdemaailma-analyysi -menetelmään.<br />
<br />
<ol>
<li>Aluksi käytettävyystestauksesta, mistä löytyy menetelmän tausta.</li>
<li>Miksi asiakkaan ymmärtäminen ei useinkaan onnistu järjestelmäsuunnittelussa?</li>
<li>Mitä tarkoittaa "kohdella asiakasta samoin kuin käyttäjää"?</li>
</ol>
<br />
<b>1. Käytettävyystestauksen keskeinen periaate</b><br />
<br />
Käytettävyystestaus on käytettävyyssuunnittelun perinteisin menetelmä. Sen kulku pääpiirteissään on:<br />
<br />
<ul>
<li>lähtökohtama on kehitettävän järjestelmän jonkintasoinen prototyyppi</li>
<li>pyydetään käyttäjiä testihenkilöiksi</li>
<li>annetaan käyttäjälle tehtäviä, joita käyttäjän pitäisi suorittaa</li>
<li>annetaan käyttäjälle ohjeistukset: </li>
<ul>
<li>"Tee tehtävä parhaasi mukaan". (usein pyydetään samalla ajattelemaan ääneen)</li>
<li>"Keskity omaan suoritukseesi, tehtäväsi ei ole arvioida käyttöliittymän hyvyyttä".</li>
<li>"Jos et osaa tehdä tehtävää, niin vika ei ole sinussa vaan suunnitteluratkaisuissa".</li>
</ul>
<li>testiä seuraava suunnittelutiimi havainnoi käyttäjän suoriutumista, yrittäen ymmärtää käyttäjän suoriutumisen perusteella, mikä suunnitteluratkaisussa toimii ja mikä ei toimi</li>
<li>korjataan suunnitteluratkaisut, jotka eivät näyttäneet toimivan</li>
</ul>
<div>
Käytettävyystestauksessa on siis keskeistä, että <i>käyttäjä on pelkästään tiedon lähde.</i> Hän toimii ainoastaan omana itsenään, kun hän yrittää tehdä tehtäviä. </div>
<div>
<br /></div>
<div>
<i>Käyttäjällä siis ei ole mitään vastuuta</i> käyttöliittymän kehittämisestä: </div>
<div>
<ul>
<li>ei analysointi- eikä jäsentämisvastuuta testin aikana</li>
<li>eikä vastuuta siitä, millainen käyttöliittymä lopulta kehitetään.</li>
</ul>
</div>
<span style="background-color: white; font-family: "cambria"; font-size: 11pt;">Jos tämän muotoilee suunnitteluperiaatteeksi, niin se voisi kuulua: </span><br />
<span style="background-color: white; font-family: "cambria"; font-size: 11pt;"><b><br /></b></span>
<br />
<div style="text-align: center;">
<i><span style="background-color: white; font-family: "cambria"; font-size: 11pt;">S</span><span style="background-color: white; font-family: "cambria"; font-size: 11pt;">uunnittelutiimi vastaa kaikesta käytettävyydestä. Käyttäjä ei mistään. </span></i></div>
<div style="text-align: center;">
<i><br /></i></div>
<div>
<span style="background-color: white; font-family: "cambria"; font-size: 11pt;"><b>2. Miksi asiakkaan ymmärtäminen ei useinkaan onnistu järjestelmäsuunnittelussa?</b></span></div>
<div>
<span style="background-color: white; font-family: "cambria"; font-size: 11pt;"><br /></span></div>
<div>
<span style="background-color: white; font-family: "cambria"; font-size: 11pt;">Järjestelmäkehityksessä asiakaslähtöisyys tarkoittaa usein asiakkaan vastuuttamista. Pyydetään asiakasta määrittämään vaatimuksia, esittämään toiveita, osallistumaan työpajoihin jne. </span></div>
<div>
<span style="background-color: white; font-family: "cambria"; font-size: 11pt;"><br /></span></div>
<div>
<span style="background-color: white; font-family: "cambria"; font-size: 14.666666984558105px;">Tämä ei yleensä vain toimi: lopputuleman laatu kun voi olla mitä tahansa. Tilanne on vähän sama kuin jos käyttäjät laitettaisiin suunnittelemaan käyttöliittymiä. (joo, tiedän, että näinkin tehdään...)</span></div>
<div>
<span style="background-color: white; font-family: "cambria"; font-size: 14.666666984558105px;"><br /></span></div>
<div>
<span style="background-color: white; font-family: "cambria"; font-size: 14.666666984558105px;">Miksi tämän tyyppinen asiakkaan osallistaminen ei toimi? </span></div>
<div>
<span style="background-color: white; font-family: "cambria"; font-size: 14.666666984558105px;"><br /></span></div>
<div>
<span style="background-color: white; font-family: "cambria"; font-size: 14.666666984558105px;">Sen vuoksi, että on hyvin sattumanvaraista, kuinka hyvin asiakkaat pystyvät jäsentämään oikein tarpeitaan ja maailmaansa. Vaatimusten, toiveiden ym. esittäminen laadukkaasti on hyvin haastava tehtävä, johon monellakaan ei ole aidosti resursseja: ei aikaa eikä usein kiinnostustakaan. </span></div>
<div>
<span style="background-color: white; font-family: "cambria"; font-size: 14.666666984558105px;"><br /></span></div>
<div>
<span style="background-color: white; font-family: "cambria"; font-size: 14.666666984558105px;">Laatuongelman ohella asiakkaan laittaminen tällaiseen työskentelyyn on myös eettisesti kyseenalaista. </span></div>
<div>
<span style="background-color: white; font-family: "cambria"; font-size: 14.666666984558105px;"><br /></span></div>
<div>
<b><span style="background-color: white; font-family: "cambria"; font-size: 11pt;">3. </span>Mitä tarkoittaa "kohdella asiakasta samoin kuin käyttäjää"?</b><br />
<br /></div>
<span style="background-color: white; font-family: "cambria"; font-size: 11pt;">Käytettävyystestauksen periaatteen (ks. yllä) voisi muotoilla j</span><span style="background-color: white; font-family: "cambria"; font-size: 11pt;">ärjestelmäsuunnittelun tasolle seuraavasti: </span><br />
<br />
<div style="text-align: center;">
<span style="background-color: white; font-family: "cambria"; font-size: 11pt;"><i>Suunnittelutiimi vastaa yksin siitä, että suunnitteluratkaisut ovat asiakkaan tarpeiden mukaiset. Asiakas ei ollenkaan. </i></span></div>
<div>
<span style="background-color: white; font-family: "cambria"; font-size: 11pt;"><br /></span></div>
<div>
<span style="background-color: white; font-family: "cambria"; font-size: 11pt;">Mitä tämä tarkoittaa käytännössä? Miten pitäisi kommunikoida asiakkaan kanssa, kun halutaan ymmärtää hänen maailmaansa ja tarpeitaan? Niin että vastuu on suunnittelutiimillä, ja tuloksena on aito asiakasymmärrys?</span></div>
<div>
<span style="background-color: white; font-family: "cambria"; font-size: 11pt;"><br /></span></div>
<div>
<span style="background-color: white; font-family: "cambria"; font-size: 11pt;">Tähän vastaa Kohdemaailma-analyysi -menetelmä. Menetelmä </span><span style="background-color: white; font-family: "cambria"; font-size: 11pt;">- ja siitä kertova kirja - esitellään webinaarissa pe 11.1. klo 13. Tässä vielä <a href="https://www.ketteratkirjat.fi/kirjat/36229" target="_blank">linkki ilmoittautumissivulle</a>. </span></div>
Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com0tag:blogger.com,1999:blog-1445256629357746536.post-22025640280810718512018-12-18T09:24:00.001+02:002018-12-18T10:40:39.905+02:00Mikä meni Nokian käyttöliittymissä pieleen?<h3>
<span style="font-family: inherit;"><b>Nokialla sai 1990-luvulla vallan erikoinen käyttöliittymäparadigma, jossa yhdeksi puhelinten segmentointitekijäksi otettiin erilaiset käyttöliittymät. Monet erilaiset käyttöliittymät osaltaan vaikuttivat Nokian luopumiseen puhelinbisneksestä.</b></span></h3>
<div style="color: #454545; font-stretch: normal; line-height: normal;">
<span style="font-family: inherit;"><br /></span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal;">
<span style="font-family: inherit;">Luin </span><b style="font-family: inherit;">Risto Siilasmaan</b><span style="font-family: inherit;"> kirjan ”</span><b style="font-family: inherit;">Paranoidi optimisti</b><span style="font-family: inherit;">”, jossa hän kertoo kokemuksistaan Nokian hallituksessa vuodesta 2008 eteenpäin. Mukaansa tempaava, mielenkiintoinen kirja!</span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal; min-height: 14px;">
<span style="font-family: inherit;"><br /></span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal; min-height: 14px;">
<span style="font-family: inherit;">Ehkä merkittävin Nokian ongelma oli se, että <b>ohjelmistokehityksen isoja ongelmia</b> ei tuotu avoimesti esiin johdolle: ei hallitukselle, mutta ei myöskään alemmille johtoportaille. Ja kun asia selvisi, oli liian myöhäistä.</span><span style="font-family: inherit;"> </span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal; min-height: 14px;">
<span style="font-family: inherit;"><br /></span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal;">
<span style="font-family: inherit;">Ohjelmistokehityksen yksi <b>osasyy oli puhelinten käyttöliittymissä</b>. Niihin liittyi kaksi selkeää ongelmaa: </span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal;">
</div>
<ol>
<li><span style="font-family: inherit;">Aluksikin, puhelinten </span><b style="font-family: inherit;">käytettävyys oli ongelmallista</b><span style="font-family: inherit;">, käytettävyys ei ollut (läheskään) Applen tasoa. </span></li>
<li><span style="font-family: inherit;">Toiseksi, Nokian </span><b style="font-family: inherit;">eri puhelimissa oli</b><span style="font-family: inherit;"> </span><b style="font-family: inherit;">erilaisia käyttöliittymiä</b><span style="font-family: inherit;">. Kun Apple pystyi keskittymään yhden käyttöliittymän kehittämiseen, niin Nokian tarvitsi paljon resursseja ylläpitämään ja kehittämään monia käyttöliittymiä.</span><span style="font-family: inherit;"> </span></li>
</ol>
<br />
<div style="color: #454545; font-stretch: normal; line-height: normal;">
<span style="font-family: inherit;">Tässä nyt keskityn tuohon jälkimmäiseen (2) ongelmaan. </span><span style="font-family: inherit;">Yk</span><span style="font-family: inherit;">sinkertainen peruskysymys on: </span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal;">
<b style="font-family: inherit;"><br /></b></div>
<div style="color: #454545; font-stretch: normal; line-height: normal; text-align: left;">
<b style="font-family: inherit;">Miksi Nokialla oli eri puhelimissa erilaisia käyttöliittymiä? </b></div>
<div style="color: #454545; font-stretch: normal; line-height: normal; min-height: 14px;">
<span style="font-family: inherit;"><br /></span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal;">
<span style="font-family: inherit;">Itse olin Nokialla Oulun yksikössä 1990-luvun loppupuolella, jolloin tämä kehitys sai alkunsa. Mitä tarkalleen tapahtui 2000-luvulla, sitä en tiedä. Mutta ainakin tilanne oli sama: erilaisia käyttöliittymiä eri puhelimissa. </span><br />
<br />
<span style="font-family: inherit;">Nokialla sai 1990-luvulla valtaa sellainen ajattelu, että <b>käyttöliittymä on yksi segmentointitekijä</b>. Eri markkinasegmenteille suunniteltiin erilaisia ominaisuuksia sisältäviä puhelimia (sinällään järkevää). </span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal;">
<span style="font-family: inherit;"><br /></span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal;">
<span style="font-family: inherit;">Mutta se, että yhdeksi segmentointitekijäksi otettiin erilaiset käyttöliittymät, oli käytettävyysmielessä tietenkin älytön ajatus.</span><span style="font-family: inherit;"> </span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal; min-height: 14px;">
<span style="font-family: inherit;"><br /></span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal;">
<span style="font-family: inherit;">Monet käyttöliittymätyylit veivät siis Nokialta paljon kehitysresursseja. Lisäksi paradigmaan liittyy (ainakin) kaksi <b>käytettävyysongelmaa</b>: </span></div>
<br />
<ol>
<li style="color: #454545; font-stretch: normal; line-height: normal; margin: 0px;"><span style="font-family: inherit;">Erilaiset käyttöliittymät tarkoittivat, että <b>eri puhelimet olivat erilaisia käyttää</b>. Kun oli oppinut käyttämään yhtä nokialaista, ei osannut käyttää toista mallia. Ilmiö näkyi myös Nokian sisällä. Nokian omatkin työntekijät kertoivat, kuinka hankalaa oli opetella käyttämään erimallista nokialaista.</span></li>
<li style="color: #454545; font-stretch: normal; line-height: normal; margin: 0px;"><span style="font-family: inherit;">Erilaiset käyttöliittymät tietenkään </span><b style="font-family: inherit;">eivät ole käytettävyydeltään saman vertaisia</b><span style="font-family: inherit;">. Ja erityisesti alemman segmentin vähänäppäimisissä malleissa oli käytettävyysongelmia. Karrikoiden voikin sanoa, että Nokian ratkaisu konkretisoitui - toki tiedostamatta - siten, että ”<i>köyhemmille saa kelvata huonompikin käytettävyys</i>”.</span><span style="font-family: inherit;"> </span></li>
</ol>
<br />
<div style="color: #454545; font-stretch: normal; line-height: normal; min-height: 14px;">
<span style="font-family: inherit;">Lienee ilmeistä, että käytettävyysasiantuntijan näkökulmasta tilanne oli vähintään turhauttava. Varsinkin kun tätä erikoista suunnitteluparadigmaa markkinoitiin Nokian sisällä ”käytettävyydellä”. (Tämän enempää en kuitenkaan mene siihen, miten tällainen kehitys sai Nokialla vallan).</span><span style="font-family: inherit;"> </span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal; min-height: 14px;">
<span style="font-family: inherit;"><br /></span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal;">
<span style="font-family: inherit;">Koin oman käytettävyysasiantuntijan roolini erittäin ristiriitaisena. Toisaalta käytettävyysasiantuntijana olin tukemassa näiden eri tyylien käytettävyyden hiomista (ja niistä tulikin kohtuullisia). Toisaalta koko ajan olin siinä ristiriitatilanteessa, että mitä paremmin tein työni, sitä enemmän välillisesti tuin tuota älytöntä monen erilaisen käyttöliittymätyylin paradigmaa. </span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal; min-height: 14px;">
<span style="font-family: inherit;"><br /></span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal;">
<span style="font-family: inherit;">Risto Siilasmaa kertoo useampaan otteeseen kirjassaan, miten hän tuoreena johtoryhmän jäsenenä oli ”arka”, eikä ottanut esiin asioita, jotka häntä vaivasivat. </span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal; min-height: 14px;">
<span style="font-family: inherit;"><br /></span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal;">
<span style="font-family: inherit;">Ehkä myös minä omalta osaltani olin ”arka”. Yritin kyllä viestiä asiasta Nokia sisällä, mutta en ehkä oikeille tahoille. Enkä välttämättä oikeilla tavoilla. Ongelma oli esimerkiksi se, että miten viestiä käytettävyyttä, <b>kun johdolle oli viestitty, että vallalla ollut paradigma ikään kuin edusti käytettävyyttä? </b></span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal; min-height: 14px;">
<span style="font-family: inherit;"><br /></span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal;">
<span style="font-family: inherit;">Kun sitten tässä tilanteessa minulle tarjottiin Oulun yliopistolta professorin tehtävän hoitamista, niin siirryin Nokialta pois. Ei mikään tavallinen ratkaisu tilanteessa, jossa Nokia oli kuumimmassa nousukierteessä. </span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal; min-height: 14px;">
<span style="font-family: inherit;"><br /></span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal; min-height: 14px;">
<span style="font-family: inherit;"><br /></span></div>
<div style="color: #454545; font-stretch: normal; line-height: normal;">
<span style="font-family: inherit;">PS. Sen ajan avaintermi oli ”käytettävyys”, ”usability”. Tänä päivänä varmaan puhuttaisiin ”käyttäjäkokemuksesta”, ”user experience”.</span><span style="font-family: "helvetica neue"; font-size: 12px;"> </span></div>
<br />
<div style="color: #454545; font-family: "Helvetica Neue"; font-size: 12px; font-stretch: normal; line-height: normal; min-height: 14px;">
<br /></div>
Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com1tag:blogger.com,1999:blog-1445256629357746536.post-14106621282649374642018-10-29T10:20:00.006+02:002019-02-26T20:11:08.292+02:00Miten parempia käytettävyyden asiantuntija-arviointeja? (ratkaisuna ei "käyttäjiä mukaan")Olin mielenkiintoisessa <a href="https://www.stncope.fi/uutiset/kayttajat-keskioon-sahkoisten-omahoitopalveluiden-suunnittelussa-empowering-patients-through-ehealth-services/" target="_blank">seminaarissa</a> (25.10.2018), jossa teemana oli "<i>Käyttäjät keskiöön terveyspalvelujen suunnittelussa</i>".<br />
<div>
<br /></div>
<div>
Yksi seminaarissa esille tullut asia oli <b>käyttäjien</b> (tässä tapauksessa lääkärien) <b>tekemät</b> asiatuntija-/heuristiset käytettävyysarvioinnit.</div>
<div>
<br /></div>
<div>
Jos olet seurannut tätä blogia (esim. <a href="http://kaytettavyysnavigoija.blogspot.com/2017/03/millainen-pitaisi-olla-jarjestelmien.html" target="_blank">tämä</a> ja <a href="http://kaytettavyysnavigoija.blogspot.com/2014/10/mina-tyhma-kayttaja.html" target="_blank">tämä</a>) ja muita kirjoituksiani (esim. <a href="https://www.eduskunta.fi/FI/tietoaeduskunnasta/julkaisut/Documents/tuvj_12+2014.pdf" target="_blank">tämä</a>, s. 61-73), niin varmaan olet huomannut, että itse <b>en suosittele tämän tyyppistä käyttäjien osallistumista</b>. Näen siinä niin eettiisiä kuin laadullisia ongelmia. </div>
<div>
<br /></div>
<div>
Peruste käyttäjien tekemille asiantuntija-arvioinneille on luonnollisesti se, että käyttäjät tuntevat sovelluksen substanssin. Ja ajatellaan, että kun käytettävyysasiantuntijat eivät tunne sovellusaluetta, niin käyttäjien substanssitietämys toisi lisäarvoa. Vaikka tuntuu loogiselta, mutta on siis lähtökohtaisesti ongelmallinen ratkaisu; syynä siis niin eettiset kuin laadulliset syyt. </div>
<div>
<br /></div>
<div>
<b>Miten tämä saada parempia käytettävyyden asiantuntija-arviointeja? </b></div>
<div>
<br /></div>
<div>
Aluksikin, käytettävyysasiantuntijoiden suorittamat asiantuntija-arvioinnit ovat aina tekijänsä näköisiä: arvointien tulokset vaihtelevat sen mukaan, kuka sattuu tekemään arvioinnin. Myös eri arvioijien lähestymistavat vaihtelevat. Itse olen päätynyt siihen tulokseen, että <b>en tee heuristisia arviointeja</b> ollenkaan; en vain näe sellaisia erityisen hyödyllisiksi. </div>
<div>
<br /></div>
<div>
Oma ratkaisuni on se, että <b>arvioinnin pohjaksi perehdyn varsin syvällisesti sovellusalueeseen</b>. Vain sitä kautta on perusteet löytää keskeiset ja tärkeimmät käytettävyysongelmat. Oma ratkaisuni perehtyä sovellusalueeseen on <b><a href="https://kaytettavyysnavigoija.blogspot.com/2019/01/uusi-kirja-julkaistu-kohdemaailma.html" target="_blank">kohdemaailma-analyysi</a></b>: </div>
<div>
<ul>
<li>tieto sovellusalueesta kerätään muutamalla haastattelulla</li>
<li>sovellusalueen ymmärtäminen perustuu omalle (ei käyttäjien) ajattelu- ja jäsennystyölle</li>
<li>haastatteluissa keskitytään arvioinnin kannalta oleellisiin asioihin (tavoitteena esimerkiksi ei alkuunkaan ole oppia lääkärin kliininen työ)</li>
<li>arvioidaan <b>sovelluksen käytettävyys</b> (eikä "käyttöliittymän käytettävyys")</li>
<li>yleensä 2 - 3 päivässä saa riittävän ymmärryksen (ei siis alkuunkaan niin kauan kuin ehkä kuvittelisi)</li>
<li>tämän jälkeen tehdään asiantuntija-arviointi</li>
</ul>
<div>
<b><a href="https://kaytettavyysnavigoija.blogspot.com/2019/01/uusi-kirja-julkaistu-kohdemaailma.html" target="_blank">Kohdemaailma-analyysiin</a></b> perustuva asiantuntija-arviointi vie luonnollisesti enemmän resursseja kuin esim. heuristinen arviointi. Mutta väitän, että tulosten syvällisyys ja merkittävyys on aivan eri luokkaa. Toisaalta se on paljon kevyempi kuin käytettävyystestit, ja tuottaa laajemmat ja syvällisemmät tulokset. (Huom! Tämä on oma kokemukseni; minulla ei ole mitään varsinaisia tutkimustuloksia näiden väitteiden tueksi. Mielellään otan haasteen vastaan...)</div>
</div>
<div>
<br /></div>
<div>
PS. Kirja <b>kohdemaailma-analyysista ilmestyy</b> vuoden 2019 alkupuolella. (seuraa tätä blogia!)</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com0tag:blogger.com,1999:blog-1445256629357746536.post-65864685681031705342018-10-16T16:02:00.004+03:002022-02-15T08:13:50.530+02:00Käyttäjäkeskeisen suunnittelun uudistettu malli<b>Päivitetty JFunnel 2.0 sisältää kaksi merkittävää aktiviteettia, jotka </b><b>yleisesti </b><b>puuttuvat tai ovat pienessä roolissa käyttäjäkeskeisen suunnittelun malleissa: (1) käyttäjäkeskeisyyden aito sitominen liiketoiminnnan tavoitteisiin sekä (2) syvällisen ymmärryksen hankkiminen kohdemaailmasta ("kehitystiimi ymmärtää paremmin asiakkaan tarpeet kuin asiakas itse"), mikä puolestaan muodostaa keskeisen perustan suunnitteluratkaisujen onnistumiselle</b><b>.</b><br />
<br />
<br />
Käytettävyyssuunnittelu (käyttäjäkeskeinen suunnittelu, ihmiskeskeinen suunnittelu, tai oikeammin "käytettävyysohjattu vuorovaikutussuunnittelu") on tapa suunnitella palveluja, järjestelmiä ja tuotteita, jotka ovat käytettävyydeltään (riittävän) hyviä.<br />
<br />
Käytettävyyssuunnittelun vaiheista on erilaisia, periaatteiltaan kuitenkin samantyyppisiä malleja. Esimerkkinä ISO 9241-210, jota olen itse käyttänyt perusreferenssinä. Kuitenkin ne ovat yleensä sen verran yleisiä, toisaalta myös usein puutteellisia, kuvauksia, että mallin soveltaja joutuu pakostakin tekemään tulkintoja.<br />
<br />
Olen kuvannut oman tulkintani käytettävyyssuunnittelusta, nimeltään <i>JFunnel</i>, kirjassani <a href="https://www.facebook.com/kaytettavyyskirja" target="_blank">Navigoi oikein käytettävyyden vesillä</a> (2010). Kuitenkin asiat ovat vuosien aikana edelleen jäsentyneet ja malli on jalostunut. Erityisesti siihen on tullut yksi hyvinkin oleellinen lisäys.<br />
<br />
Seuraavassa kuvaan tiivistetysti päivitetyn mallin, <i>JFunnel 2.0, </i>määrittelemät käytettävyyssuunnittelun vaiheet. (kuvan saa klikkaamalla suuremmaksi)<br />
<i><br /></i>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjx6JeTMR454fZ30lg9wBgsNodOqxOvgy2O8ulpcvbseoRHqkJVnxkp8CKB0lNDSRv2t7b3jy6-bFh4VXulOFRvfnfqNOV_eu2aEOaXp8co2H2ovkuMTdBP_pJt6F05nJxpD5d1FJzOckk/s1600/Na%25CC%2588ytto%25CC%2588kuva+2018-10-16+kello+15.57.32.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="800" data-original-width="1280" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjx6JeTMR454fZ30lg9wBgsNodOqxOvgy2O8ulpcvbseoRHqkJVnxkp8CKB0lNDSRv2t7b3jy6-bFh4VXulOFRvfnfqNOV_eu2aEOaXp8co2H2ovkuMTdBP_pJt6F05nJxpD5d1FJzOckk/w640-h400/Na%25CC%2588ytto%25CC%2588kuva+2018-10-16+kello+15.57.32.png" width="640" /></a></div>
<i><br /></i>
<br />
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<b>0. Kohdemaailma-analyysi</b></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Katso kuvaus lopusta. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<b>1. "Haluttu käytettävyyden vaikuttavuus" </b></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Määrittää ne liiketoiminnalliset hyödyt, joita (riittävän) hyvällä käytettävyydellä tavoitellaan. Tämä voi koostua useista eri hyödyistä. Oleellista on, että hyödyt ovat aidosti liiketoiminnasta vastaavien päätöksiä. Samoin oleellista on, että hyödyt määritetään mittarein ja tavoitetasoin. Esimerkiksi hyötytavoite voi olla, että turhien tukipuhelujen lukumäärä putoaa 90%. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Tämä vaihe on sellainen, joka monista muista malleista puuttuu (myös ISO 9241-210:sta). </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<b>2. Käyttäjäryhmien määritys</b></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Yleinen käytettävyyssuunnittelun perustehtävä: tunnistettava (tärkeimmät) käyttäjäryhmät. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<b>3. Käyttäjien halutut aikaansaannokset</b></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Tämän vaiheen kohdalla useissa muissa malleissa on "käyttäjätehtävien analyysi" tms. "Halutut aikaansaannokset" korostaa sitä, että oleellisempaa on ymmärtää, mitä käyttäjien tulisi saada aikaiseksi, kuin se, miten käyttäjä käyttää järjestelmää. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<b>4. Käytettävyysvaatimukset</b></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Tässä määritetään käytettävyysvaatimukset: minkä tasoinen käytettävyys pitäisi olla, jotta sillä saavutettaisiin "haluttu käytettävyyden vaikuttavuus" (vaihe 1). Ainoa toimiva tapa määrittää käytettävyysvaatimukset on perustaa ne käyttäjien suoriutumiseen. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Käytettävyysvaatimukset tulee (luonnollisesti) määritellä mitattavasti. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<b>5. Vuorovaikutusratkaisujen suunnittelu</b></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Jos vaiheet 1 - 4 ovat luonteeltaan analyyttisiä (ymmärtää käyttäjiä, ymmärtää mitä halutaan), niin tämä vaihe on luonteeltaan konstruktiivinen: suunnitteluratkaisujen tuottaminen. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Suunnittelua ohjaavat toisaalta vaiheiden 1 - 4 tulokset, toisaalta yleiset suunnitteluohjeistot ja teknologiset rajoitukset ja mahdollisuudet. Myöhemmässä vaiheessa suunnittelua ohjaavat myös vaiheiden 6 ja 7 tulokset. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<b>6. Käytettävyyspalaute</b></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Tässä vaiheessa haetaan arvioinneilla ja testeillä laadullista palautetta suunnitteluratkaisujen onnistumisesta. Parempia suunnitteluratkaisuja kehitetään ongelmakohtien ratkaisemiseksi (eli palataan vaiheeseen 5). </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<b>7. Käytettävyyden todentaminen</b></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Kun muodostunut käsitys, että suunnitteluratkaisu voisi olla riittävän hyvä, niin ratkaisu todennetaan todentamistesteillä. Toisin sanoen, mitataan, saavutetaanko asetetut käytettävyysvaatimukset (vaihe 4). </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Jos vaatimukset saavutetaan, niin suunnitteluratkaisu on käytettävyyden näkökulmasta valmis. Jos taas vaatimukset eivät täyty, pitää palata vaiheisiin 5 ja 6. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<b>8. Halutun käytettävyyden vaikuttavuuden todentaminen</b></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Tämä voidaan todentaa vasta sen jälkeen, kun järjestelmä on ollut käytössä jo jonkin aikaa. Eli jos tavoitteeksi oli asetettu (vaihe 1), että "tukipuhelut vähenevät 90%", niin mitataan, missä määrin tämä tavoite toteutuu. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<b>0. Kohdemaailma-analyysi</b></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Kohdemaailma-analyysi vaihe puuttui kokonaan Navigoi oikein käytettävyyden vesillä -kirjasta. Tämä on "erilainen" aiemmista vaiheista, koska se ei ole suoraan käytettävyyssuunnittelua. Kuitenkin se on oleellinen perusta sille, että käytettävyyssuunnittelu onnistuu. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Kohdemaailma on se asiakkaan reaalimaailma, jota kehitettävä tuote, järjestelmä tai palvelu on suunniteltu toiminnallisesti tukemaan. Esimerkiksi kun kehitetään yliopiston tohtorikoulutusta tukeva tietojärjestelmä, kohdemaailma on yliopiston tohtorikoulutus. Vastaavasti kohdemaailma on sairaalaan ilmoittautuminen (itseilmoittautumisjärjestelmä), lääkärien erikoistumiskoulutus (erikoistumiskoulutuksen hallintaohjelmisto) ja yrityksen toiminta (toiminnanohjausjärjestelmä). </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Kohdemaailma-analyysin tavoite on, että kehitystiimi tuntee kohdemaailman syvällisesti, "paremmin kuin asiakas itse". Vastoin kuin ehkä luulisi, tämä ei suinkaan ole mikään kohtuuton tavoite. Oma havaintoni vuosien ajalta on, että merkittävät käytettävyysongelmat johtuvat siitä, että suunnittelijoilla on ollut vajaavainen tai väärä ymmärrys kohdemaailmasta. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Eli yleissuositus: ensin kohdemaailma-analyysi, ja vasta sitten käytettävyyssuunnittelun muut vaiheet. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">Päivitys: Kohdemaailma-analyysista on ilmestynyt kirja: <a href="https://www.ketteratkirjat.fi/kirjat/36229">https://www.ketteratkirjat.fi/kirjat/36229</a> </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<br />
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<br />Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com1tag:blogger.com,1999:blog-1445256629357746536.post-27067823643438181412018-08-31T11:55:00.001+03:002018-08-31T11:59:08.955+03:00SUS (System Usability Scale) suomeksiOlen kääntänyt joskus SUS:n (System Usability Scale) suomeksi.<br />
<br />
Tuli yhteydenotto, jossa halutaan viitata ko. käännökseen. Laitanpa sen nyt näkyviin tähän blogiin, niin käännöksen löytää ja siihen voi viitata helpommin.<br />
<br />
<div class="separator" style="clear: both; text-align: left;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhCbAaIbGRTDR8MJDr0KuGSu87xFy9Tbjo-VrYNk_YPsEXmKwCk424onJyrIYAQWchsj8NsUoCxp9oaIyp56eefwXAo5zFdTMOdJuuWeUenPpSUxnikbC5ZbMSo176BZzg-eI2NZFiJe6E/s1600/Na%25CC%2588ytto%25CC%2588kuva+2018-8-31+kello+11.47.12.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em; text-align: center;"><img border="0" data-original-height="645" data-original-width="583" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhCbAaIbGRTDR8MJDr0KuGSu87xFy9Tbjo-VrYNk_YPsEXmKwCk424onJyrIYAQWchsj8NsUoCxp9oaIyp56eefwXAo5zFdTMOdJuuWeUenPpSUxnikbC5ZbMSo176BZzg-eI2NZFiJe6E/s1600/Na%25CC%2588ytto%25CC%2588kuva+2018-8-31+kello+11.47.12.png" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
Lisätietoa SUS:sta on John Brooken alkuperäisartikkelissa "SUS - A quick and dirty usability scale", joka löytyy googlaamalla. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
PS. SUS:sta on tehty myös "positiivinen" versio P-SUS, josta olen kirjoittanut <a href="http://kaytettavyysnavigoija.blogspot.com/2013/05/p-sus-positiviinen-sus-kysely-suomeksi.html" target="_blank">täällä</a>. </div>
<br />Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com5tag:blogger.com,1999:blog-1445256629357746536.post-46590137516227988692018-04-20T08:49:00.002+03:002022-04-30T09:19:33.910+03:00Hyvän mielipidekirjoituksen kaava: Miten saada mielipidekirjoitus käytettävyydestä (ja muustakin) läpi Helsingin sanomiin?Kirjoitin Helsingin sanomiin mielipiteen 17.4.2018, ja se julkaistiin seuraavana päivänä (18.4.2018, kuva tämän kirjoituksen lopussa). Mielipidekirjoitukseni aihe on sama kuin mikä monissa aiemmissa: käytettävyys ja siihen liittyen erityisesti julkinen hankinta. Tässä tapauksessa casena on Apotti, mitä olen myös käsitellyt aiemmin niin blogissa kuin myös Hesarissa.<br />
<br />
Tämä on 11. mielipidekirjoitukseni Hesariin (<a href="https://kaytettavyysnavigoija.blogspot.com/2022/01/artikkelini-helsingin-sanomissa-kokoelma.html" target="_blank">luettelo löytyy tästä)</a>, joka on julkaistu muutaman viime vuoden aikana. Suurin osa niistä käsittelee käytettävyyttä ja julkista hankintaa, mutta on myös muutama yhteiskunnallinen mielipide. Lisäksi olen kirjoittanut Hesariin kaksi vieraskynää. Kirjoitusteni läpäisyprosentti on ollut reilusti yli 50, mikä mielestäni on korkea. Tietääkseni Hesariin tulee paljon mielipidekirjoitusehdotuksia, joista vain murto-osa hyväksytään.<br />
<div>
<br /></div>
Tässä blogikirjoituksessa en nyt keskity käytettävyyteen, en julkiseen hankintaan enkä Apottiin - käytettävyyssubstanssi on kerrottu mielipiteessä alla. Sen sijaan tarkoitukseni on kertoa, <i>miten kokemukseni mukaan kannattaa kirjoittaa mielipide</i> niin, että sillä on hyvät mahdollisuudet tulla hyväksytyksi Hesariin (ja varmaan muuallekin).<br />
<br />
Eli tässä on<b> hyvän mielipidekirjoituksen kaavani</b>. Voit verrata sitä tämän kirjoituksen lopussa olevaan kopioon mielipideosastelle lähettämästäni sähköpostista:<br />
<br />
A Tekniset seikat<br />
<ol>
<li>Sähköpostin otsikoksi olen yleensä laittanut yksinkertaisesti "Ehdotus mielipideosastolle" </li>
<li>En ole yleensä kirjoittanut sähköpostiin mitään pidempää saatetta; kertonut vain, että tässä on ehdotus mielipidepalstalle (kuten tässä). Tosin kun kirjoitin <a href="https://drive.google.com/file/d/1JtQHzIVtKdDRx2ybuJa_2TPAH3b2VHLQ/view?usp=sharing" target="_blank">graduohjemielipidettä</a>, niin kirjoitin saatetekstiin, että ehdotuksestani tuli "<i>vähän ”opettava”, enkä tiedä sopiiko mielipidepalstalle. Mutta harkittavaksenne kuitenkin</i>". Ehkä kannattaa olla mieluummin vähän vaatimaton kuin korostaa itseään?</li>
<li>Oma nimi ja yhteystiedot</li>
<li>Selkeä erotin (esim. katkoviiva), josta näkee mihin saateteksti päättyy ja mistä varsinainen mielipide alkaa.</li>
<li>Kirjoitan suoraan sähköpostin runkoon, enkä tee erillistä dokumenttia. Ajattelen, että toimittajan on helpompi lukea (lyhyt) teksti suoraan sähköpostista kuin avata liitettä. </li>
<li>Alle nimi, titteli, mitkä haluaa näkyvän mielipidekirjoituksessa ja paikkakunta.</li>
</ol>
<div>
B Aiheen valinta</div>
<ol>
<li>Aiheen on oltava ajankohtainen. Olen usein omissa kirjoituksissani viitannut mielipiteen alussa johonkin edellisten päivien huomiota herättävään juttuun tai pääkirjoitukseen Hesarissa. Kuten myös tässä tapauksessa: mielipidekirjoituksessani viittasin juttuun "<a href="https://www.hs.fi/kaupunki/art-2000005644392.html" target="_blank">Vantaalle palkataan hoitajien sijaisia vakiväkeä huomattavasti kovemmalla palkalla...</a>" </li>
<li>Kirjoituksella pitää olla jonkin "pihvi": (poikkeava) näkökulma, jonka haluaa tuoda esille. Tässä viimeisessä kirjoituksessa otin esiin näkökulman, mitä ei suoraan sanottu jutussa mutta joka on tunnettu aiemmista uutisista. <a href="https://www.hs.fi/mielipide/art-2000002632417.html" target="_blank">Tässä vanhemmassa kirjoituksessa</a> toin esiin näkemyksen, jossa haastettiin pääkirjoituksen väite. </li>
</ol>
C Kirjoittaminen<br />
<ol><ol></ol>
<li>Pääohje: tiivistä, yksinkertaista, karsi, tiivistä, yksinkertaista ja karsi. Lopputuloksena lyhyt ja fokusoitunut juttu, jossa ei ole rönsyjä. Luultavasti joudut jättämään monta mielestäsi tärkeää näkökulmaa pois. </li>
<li>Jos kyse on ammatillisesta asiasta, niin asiaa on kansanomaistettava. Jos toimittaja ei ymmärrä, niin tuskin julkaistaan. Hyväksy, että "oiot" tekstissä. Sisällön ei tarvitse olla tieteellisessä mielessä tarkka. </li>
<li>Teksti pitää kirjoittaa hyvin jäsennellyksi. Perustapa tähän on, että pyörittelet, jäsentelet ja editoit tekstiä jonkin aikaa - harvoin tulee hyvää jälkeä kerralla (ainakaan minulla). Tämän viimeisen mielipiteen kirjoittamiseen minulla meni aikaa vain puolisen tuntia - ehkä johtuen siitä, että olen niin usein aiemmin kirjoittanut aiheesta. Mutta helposti lyhyenkin tekstin pyörittelyssä menee parikin tuntia. </li>
<li>Jos kirjoittaa poliittisesta tai yhteiskunnallisesta asiasta, niin pitää pyrkiä mahdollisimman neutraaliin ilmaisuun. </li>
<li>Loppuun olen yrittänyt laittaa poleemisen noston (tässä tapauksessa <i>"Hankintamenettelyn puutteita ei pelastanut edes se, että lukijalle tehtiin tietojen mukaan massiivisiakin käyttäjätestejä ennen sen käyttööotttoa"</i>).</li>
<li>Itse olen ehdottanut otsikkoa (<i>"Otsikko esim. ..."</i>), tietäen että toimitus usein muotoilee otsikon itse. Kirjoitan otsikon aina ihan viimeisenä asiana, ja yritän muotoilla joka tapauksessa sen lyhyeksi ja iskeväksi. Tässä tapauksessa otsikkoehdotukseni otettiin vähän muotoiltuna.</li>
</ol>
<div>
Alla kopio mielipideosastolle lähettämästäni sähköpostistani. Siitä näkyy myös se, missä määrin toimitus muokkasi alkuperäistä tekstiäni.<br />
<br />
(yllä olevaa tekstiä editoitu 24.4, tarkoituksena selkeyttää kaavaa)</div>
<div>
<br /></div>
<div>
<span style="font-family: "helvetica"; font-size: 12px;">------------------------------------------</span><br />
<span style="font-family: "helvetica"; font-size: 12px;"><br /></span></div>
<div>
<span style="font-family: "helvetica"; font-size: 12px;">(Sähköpostin otsikko: "ehdotus mielipidepalstalle")</span><br />
<br />
<span style="font-family: "helvetica"; font-size: 12px;"><br /></span>
<span style="font-family: "helvetica"; font-size: 12px;">hei,</span><br />
<br style="font-family: Helvetica; font-size: 12px;" />
<span style="font-family: "helvetica"; font-size: 12px;">alla oleva mielipide ehdolle mielipidepalstalle. </span><br />
<br style="font-family: Helvetica; font-size: 12px;" />
<span style="font-family: "helvetica"; font-size: 12px;">terv. Timo Jokela</span><br />
<span style="font-family: "helvetica";"><span style="font-size: 12px;">(<i>tähän yhteystiedot</i>)</span></span><br />
<span style="font-family: "helvetica"; font-size: 12px;">——————————</span><br />
<br style="font-family: Helvetica; font-size: 12px;" />
<span style="font-family: "helvetica"; font-size: 12px;">Otsikko esim: ”Apotista tulikin vaikeakäyttöinen?"</span><br />
<br style="font-family: Helvetica; font-size: 12px;" />
<span style="font-family: "helvetica"; font-size: 12px;">Vantaalla on aiheuttanut närää se, että Apotti-potilastietojärjestelmän käyttöönottoa varten palkataan henkilöitä korkeammalla palkalla kuin mikä on hoitohenkilöstön palkkataso (HS 17.4.). Tätä perustellaan sillä, että "Apotin täytäntöönpano on varsin kova ponnistus, jonka onnistuminen pitää varmistaa”. </span><br />
<br style="font-family: Helvetica; font-size: 12px;" />
<span style="font-family: "helvetica"; font-size: 12px;">Monissa aiemmissa yhteyksissä on sanottu, että Apotin hankinnan yksi tavoite oli ”käytettävyys”. Toisin sanoen, että Apotti-järjestelmän käyttö olisi helppo oppia. Uutisen mukaan näyttää nyt kuitenkin siltä, että järjestelmän helppokäyttöisyyteen ei aidosti uskota. </span><br />
<br style="font-family: Helvetica; font-size: 12px;" />
<span style="font-family: "helvetica"; font-size: 12px;">Helppokäyttöisyyden yksi yleinen peruskriteeri on, että substanssiosaajat - terveydenhuollon järjestelmän kyseessä ollessa esimerkiksi lääkärit ja sairaanhoitajat - osaavat käyttää uuttakin järjestelmää ilman koulutusta. Jos uusi järjestelmä tarkoittaa merkittäviä muutoksia prosesseihin tai työnkulkuihin, niin koulutus voi olla perusteltua. Mutta jos järjestelmä on aidosti helppokäyttöinen, se ohjaa myös uusiin toimintatapoihin. Käyttöönoton ei missään tapauksessa pitäisi olla ”kova ponnistus”, ja sitä varten pitäisi riittää kevyehkö koulutus. </span><br />
<br style="font-family: Helvetica; font-size: 12px;" />
<span style="font-family: "helvetica"; font-size: 12px;">Hyvässä tapauksessa pelko Apotin käyttöönoton haasteellisuudesta on turha. Voi olla, että Apotti on aidosti helppokäyttöinen. </span><br />
<br style="font-family: Helvetica; font-size: 12px;" />
<span style="font-family: "helvetica"; font-size: 12px;">Kuitenkin Apotin kilpailutuksesta saatujen tietojen mukaan käytettävyys on huomioitu samaan tyyliin kuin monessa aiemmassa julkisessa hankinnassa. Kokemus osoittaa, että nykyiset hankintatavat eivät takaa helppokäyttöisyyttä. Käytettävyys on ollut ”tärkeä” kriteeri monessa aiemmassakin julkisessa hankinnassa, ja epäonnistuttu. Hyvänä esimerkkinä pääkaupunkiseudun matkakortinlukijan hankinta, jonka käytettävyys tunnetusti epäonnistui. Hankintamenettelyn puutteita ei pelastanut edes se, että lukijalle tehtiin tietojen mukaan massiivisiakin käyttäjätestejä ennen sen käyttööotttoa. </span><br />
<br style="font-family: Helvetica; font-size: 12px;" />
<span style="font-family: "helvetica"; font-size: 12px;">Timo Jokela, FT, dosentti</span><br />
<span style="font-family: "helvetica"; font-size: 12px;">Helsinki</span></div>
<div>
<span style="font-family: "helvetica"; font-size: 12px;"><br /></span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1EUO2RlzqiJnxdKTYcm08J0M7nslG2ydODv_GuZtUOMWn5oNW88lkg78IVOeySUmeASCXXisakPBMDuK4u46endP0IxUfCWJGaj6cn_p3EPtJFqigk-uZsTX6otbJo8TR1KolqfzWQFI/s1600/Hesari+180418.jpeg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="655" data-original-width="648" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1EUO2RlzqiJnxdKTYcm08J0M7nslG2ydODv_GuZtUOMWn5oNW88lkg78IVOeySUmeASCXXisakPBMDuK4u46endP0IxUfCWJGaj6cn_p3EPtJFqigk-uZsTX6otbJo8TR1KolqfzWQFI/s640/Hesari+180418.jpeg" width="632" /></a></div>
<div>
<span style="font-family: "helvetica"; font-size: 12px;"><br /></span></div>
Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com0tag:blogger.com,1999:blog-1445256629357746536.post-5603051424725408722017-12-01T06:47:00.001+02:002017-12-01T06:47:13.867+02:00Miten varmistaa käytettävyys, jos käyttäjäkeskeinen suunnittelu ei sitä varmista? <a href="https://timojokela.teachable.com/" target="_blank">Tuntematon käytettävyys</a> -kurssin osassa 3 kerroin, miksi käyttäjäkeskeinen suunnittelu ei takaa käytettävyyttä.<br />
<br />
<a href="https://timojokela.teachable.com/" target="_blank">Osassa 4</a> nyt kerron, mikä on se tapa, miten varmistaa käytettävyys. Videon mitta on 5 min 6 s.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://timojokela.teachable.com/" target="_blank"><img border="0" data-original-height="800" data-original-width="1280" height="250" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEid-O6o8f-XrlTq9JX-SRtPLnAh_h2u0fG4_sKwpiUAxChMuuYEEZWnipmEXz0QvxTxP7Sgtn8JgoFvDO_QLUCDWkL5bgM66AKRCDORaq7gbqnCFluePweKSpXvF3iiP61hAijVxjAPkWA/s400/Na%25CC%2588ytto%25CC%2588kuva+2017-12-01+kello+6.39.41.png" width="400" /></a></div>
<br />Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com0tag:blogger.com,1999:blog-1445256629357746536.post-47864677287596736112017-11-24T10:25:00.003+02:002017-11-24T10:25:36.185+02:00Miksi tuloksena on huonoa käytettävyyttä, vaikka tehdään ehkä paljonkin käyttäjäkeskeistä suunnittelua?Verkkokurssi Tuntematon käytettävyys jatkuu. Osa vastaa kysymykseen:<br />
<br />
<i>Miksi tuloksena on huonoa käytettävyyttä, vaikka tehdään ehkä paljonkin käyttäjäkeskeistä suunnittelua?</i><br />
<div>
<br /></div>
Katso video (5 min 30 s) <a href="https://timojokela.teachable.com/" target="_blank">tästä</a>.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjAqaXhj1ZYGp-9FFkjUaYaB7IuMhhY8_WMAKwtmjBx1dGs06yDq5Hzc5v9mfK37pnV2txwnhMITmeZr-1TPpeM2rU8Xgv0GbBQdYCiRPrpy2CBuZMggotjZtPAXIU-pDayw70ZTYPwICc/s1600/Na%25CC%2588ytto%25CC%2588kuva+2017-11-24+kello+10.24.35.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="800" data-original-width="1280" height="250" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjAqaXhj1ZYGp-9FFkjUaYaB7IuMhhY8_WMAKwtmjBx1dGs06yDq5Hzc5v9mfK37pnV2txwnhMITmeZr-1TPpeM2rU8Xgv0GbBQdYCiRPrpy2CBuZMggotjZtPAXIU-pDayw70ZTYPwICc/s400/Na%25CC%2588ytto%25CC%2588kuva+2017-11-24+kello+10.24.35.png" width="400" /></a></div>
<br />Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com0tag:blogger.com,1999:blog-1445256629357746536.post-70603531176403580692017-11-16T08:32:00.005+02:002017-11-16T08:36:43.956+02:00Mikä suunnitteluratkaisu on kriittisin käytettävyyden saavuttamiseksi?Verkkokurssi <b><a href="https://timojokela.teachable.com/" target="_blank">Tuntematon käytettävyys</a></b> jatkuu.<br />
<br />
Osassa 2 vastaan kysymykseen: <i>Mikä suunnitteluratkaisu on kriittisin käytettävyyden saavuttamiseksi? </i>Alaotsikkona <i>Vastaus EI ole "käyttöliittymä".</i><br />
<br />
Katso <a href="http://timojokela.teachable.com/" target="_blank">luentovideo</a> (6 min 35 s).<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://timojokela.teachable.com/" target="_blank"><img border="0" data-original-height="800" data-original-width="1280" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjj3Tkp3mOfGxwi-tbpx3mPFewYJZ-gZX4p7Qnrn-IYkWE1MTlk7d9GYvja5p0N_sSeDQQmE6TWxkB7G5KNb1KrOcT5gFKun1whwqOxKmAn72FG75dOVaQTRdDelGENcp-WrmhyphenhyphenVYPAzGM/s320/Na%25CC%2588ytto%25CC%2588kuva+2017-11-15+kello+9.44.56.png" width="320" /></a></div>
<br />Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com0tag:blogger.com,1999:blog-1445256629357746536.post-33799279464040887582017-10-31T09:27:00.001+02:002017-10-31T09:30:35.635+02:00Ilmainen verkkokurssi "Tuntematon käytettävyys" alkaa kohta...<div style="line-height: 24px; margin-bottom: 10px; margin-top: 10px; padding: 0px;">
Suomi 100 vuotta -teemaa juhlistetaan monin tempauksin. Ja ajattelin, että miksei juhlavuotta voisi juhlistaa myös yhdellä käytettävyyskurssilla. Niinpä pidän syksyn aikana (ilmaisen) <b>Tuntematon käytettävyys</b> <b>-verkkokurssin</b>.<br />
<br />
Kurssin nimi on tietenkin mukailtu tunnetusta kansallisromaanista, mutta se kuvaa myös kurssin sisältöä. Jonka voi tiivistää: <i>Mitä jokaisen olisi tiedettävä käytettävyydestä ja käyttäjäkeskeisestä suunnittelusta, mutta mitä kaikki asiantuntijatkaan eivät tiedä. </i><br />
<br />
Havaintoni on, että jo pelkästään termi "käytettävyys" ymmärretään kovin monin tavoin. Ja kun termien sisältö on epäselvä, niin ei ihme että keskustelu tökkii ja päätöksenteossa tehdään virheitä.<br />
<br />
Kurssi on tiivis esitys tärkeimmistä ydinasioista, joiden uskon olevan kiinnostavia kaikille tietojärjestelmien kehitystyössä ja niiden hankinnoissa mukana oleville. Kurssi vastaa mm. seuraaviin kysymyksiin:<br />
<ul>
<li>Mitä oikeasti on "käytettävyys"? (ja mitä ei)</li>
<li>Mitkä ovat keskeisimmät toimenpiteet, joiden kautta varmistetaan järjestelmän käytettävyys? </li>
<li>Miksi korkeatasoinenkaan käyttöliittymäsuunnittelu ei takaa hyvää käytettävyyttä?</li>
<li>Mitkä suunnitteluratkaisut ovat kriittisiä käytettävyyden saavuttamiseksi? </li>
<li>Millaisia ovat aidot, toimivat käytettävyysvaatimukset?</li>
<li>Millaista on "oikea" käyttäjäkeskeisyys: miten käyttäjät mukaan kehityshankkeeseen, ja miten ei?</li>
<li>Miten haastatella käyttäjiä, ja miten? Miksi esimerkiksi käyttäjien mielipiteiden kysyminen ei ole suositeltavaa eikä tuloksellista?</li>
<li>Millä tavalla käytettävyydestä pitäisi keskustella liiketoimintajohdon kanssa? Miksi käytettävyyttä ei tarvitse "myydä" liiketoimintajohdolle? </li>
</ul>
... <br />
Tavoitteena on, että tämän lyhyen kurssin jälkeen olet käytettävyyden ja käyttäjäkeskeisen suunnittelun keskeisten asioiden asiantuntija (käytännön tason käyttäjäkeskeinen suunnittelu on sitten laajempien kurssien asia). Tiedät ja ymmärrät keskeiset asiat niin, että voit asiantuntemuksella olla mukana ohjaamassa ja arvioimassa kehityshankkeiden käytettävyystyötä.<br />
<br />
Pysy kuulolla! Seuraa blogia tai liity postituslistalleni <a href="https://joticon.us2.list-manage.com/track/click?u=d0594330e9380e2aee6af03fd&id=a7fd3c5f50&e=a79d4fc96d">tästä</a><span style="font-family: "helvetica";">!</span></div>
Timo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.com0