fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi en fi fi fi en fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi en fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi en fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi en fi fi en fi fi fi fi fi en fi fi fi fi fi fi en fi fi fi fi fi fi fi en fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi en fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi eo cs fi fi fi fi fi fi en fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi cs fi fi fi fi fi fi fi fi cs fi fi fi fi fi fi nb fi fi it fi fi en fi fi fi
Yksi vaikeakäyttöinen järjestelmä lisää kouluihin?
Kuntien Tiera Oy:n oppimisympäristön hankintailmoituksessa käytettävyys on korostetusti esillä mutta siten, että valituksi voi tulla käytettävyydeltään huonoin vaihtoehto.
Hankintailmoitus on osallistumispyyntö rajoitettuun neuvottelumenettelyyn, eli siinä haetaan rajoitettu määrä toimittajia, joiden kassa neuvotellaan. Neuvottelujen perusteella sitten Kuntien Tiera laatii tarjouspyynnön, joka ei ole julkinen eikä sitä siten pääse näkemään.
Hankintailmoitus ei siis sisällä tarjouspyyntöä.  Kuitenkin hankintailmoituksessa kerrotaan, miten käytettävyys aiotaan huomioida tarjouspyynnössä.  Hankintailmoituksessa lukee:
"7. Käytettävyyden testaus osana tarjousten vertailua
Tarjottujen tuotteiden käytettävyys tullaan testaamaan osana tarjousten arviointia tarjousten vastaanottamisen jälkeen. Niille toimijoille, joille tarjouspyyntö lähetetään, tulee tarjota demo- tai vastaava ympäristö ja tarvittava määrä käyttäjätunnuksia käytettävyyden testaamista varten viikolle 6. Testausta tullaan tekemään alakoulu- yläkoulu- ja lukiotasolla. Käytettävyystestaukselle vaadittavat järjestelyt kuvataan tarkemmin tarjouspyynnössä.
Käytettävyys on vain osa tarjousten kokonaistaloudellisuuden arviointia. Vertailuperusteet kuvataan täsmällisesti tarjouspyynnössä."
Vaikka kuvaus on aika suppea, siitä selviää keskeiset periaatteet: käytettävyys on osa vertailuperusteita, ja vertailu tehdään demojen käytettävyystestauksilla.
Ensi silmäyksellä voi saada kuvan, että kilpailutuksessa pärjää sellainen oppimisympäristö, jonka käytettävyys on hyvä tai paras. Näin kuitenkaan ei ole. Itse asiassa kuvatulla menettelyllä on aika sattumanvaraista, millainen valitun oppimisympäristön käytettävyys on, niin absoluuttisesti kuin suhteissa kilpaileviin vaihtoehtoihin. Alla tarkempi analyysi.
Aloitetaan hyvästä puolesta. Hyvää on se, että lähestymistapa perustuu käyttäjien suoriutumisen arviointiin. Ja tämä on oikea tapa. Käyttäjien suoriutuminen on viime kädessä ainoa validi käytettävyyden kriteeri.
Hankintailmoituksen käytettävyysosion ongelmat ovat sen kummatkin keskeiset periaatteet: (1) käytettävyys on osana vertailuperusteita, ja (2) määrällinen käytettävyystesti tehdään demoilla. Kumpikin näistä piirteistä yksistään riittäisi siihen, että valituksi voi tulla käytettävyydeltään huonoin vaihtoehto.
Ongelma hankintailmoituksen lähestymistavassa on se, että käytettävyys (laatu) on vertailuperusteissa eikä pakollisissa vaatimuksissa. Jos aidosti halutaan käytettävyyttä (tai muuta laatua), käytettävyyden (laadun) paikka on pakolliset vaatimukset eikä vertailuperusteet.
Aluksikin, kun käytettävyyttä verrataan, niin kyse on määrällisestä käytettävyystestauksesta, koska tuloksena tarvitaan arvosanoja. Yleisin käytettävyystestauksen muoto on laadullinen testaus, jonka tavoitteena on löytää suunnitteluongelmia (ja -vahvuuksia) järjestelmästä. Mutta tästähän ei vertailutyyppisessä testauksessa voi olla kyse, vaan siis määrällisestä testauksesta.
Määrällisessä käytettävyystestauksessa mitataan käyttäjien suoriutumista annetuista tehtävistä. Ja vertailutilanteessa tasapuolisen kohtelun vuoksi käyttäjiä ei saa auttaa tms., vaan käyttäjien on suoriuduttava tehtävistä täysin itsenäisesti.
Määrällisessä käytettävyystestauksessa on tyypillistä, että käyttäjien suoriutumiseen voi vaikuttaa merkittävästi pieni yksityiskohtaisen tason suunnitteluratkaisu. Käyttäjän suoritus saattaa pysähtyä esimerkiksi siihen, että käyttöliittymässä on termi, jota käyttäjä ei ymmärrä.
Kun demot eivät ole yksityiskohdiltaan lopullisia järjestelmiä, niin niissä tällaisia "viilaamattomia" suunnitteluratkaisuja voi olla useitakin. Sen vuoksi demo saattaa saada määrällisessä käytettävyystestissä huonot pisteet, vaikka käyttäjälle ongelmia aiheuttavia piirteitä ei olisikaan lopullisessa toteutuksessa ja perustaltaan järjestelmä olisi muutenkin käytettävyydeltään hyvä.
Tämän vuoksi demojen määrällinen käytettävyystestaus ei ole validi menetelmä.  Siinä mitataan demon käytettävyyttä, ja testitulos voi olla ihan eri kuin jos olisi testattu lopullista järjestelmää. Huonot pisteet voi saada järjestelmä, jonka lopullinen toteutus olisi käytettävyydeltään korkealuokkainen.
- Ja vielä yksi käytännön näkökulma. Hankintailmoituksen mukaan rajoitettuun menettelyyn valitaan viisi ehdokasta. Totean vain, että on aikamoinen haaste suunnitella ja toteuttaa vertaileva käytettävyystesti viiden järjestelmän välillä niin, että se tehdään syrjimättömästi ja että tulokset ovat valideja (= että paljastavat aidosti parhaan järjestelmän). No, jos testit tehdään demoilla, niin tulosten validius on siis joka tapauksessa ongelma kuten edellä olen todennut.
Valituksi voi tulla oppimisympäristö, joka on käytettävyydeltään "mitä tahansa", niin absoluuttisesti kuin suhteissa kilpaileviin vaihtoehtoihin:
Valituksi voi tulla oppimisympäristö, joka saa parhaat pisteet käytettävyydestä. Mutta valituksi voi myös tulla järjestelmä, joka se saa huonoimmat pisteet käytettävyydestä.
Parhaat pisteet käytettävyydestä voi saada järjestelmä, joka on käytettävyydeltään paras. Mutta myös käytettävyydeltään huonoin järjestelmä voi saada parhaat pisteet.
Hyvässä tapauksessa asiakaskunnat voivat saada helppokäyttöisen oppimisympäristön. Mutta mahdollista on, että valituksi tulee ympäristö, jonka seurauksena on pähkäileviä käyttäjiä, vastahankaista käyttöönottoa, korkeita koulutuskustannuksia, jatkuvaa tuen tarvetta, käyttövirheitä ja kaiken maailman sekaannuksia.
Mikä olisi oikea tapa huomioida käytettävyys tarjouspyynnössä?
Perusaskel on määrittää käytettävyys pakollisiin vaatimuksiin. Siis määrittää se, mikä on riittävän hyvä taso järjestelmän käytettävyydelle. Tämän itse asiassa voinee vieläkin tehdä oppimisympäristön kilpailutuksessa, koska toki käytettävyys voi olla pakollisissakin vaatimuksissa sen lisäksi, että se on vertailuperusteissa.
Ja toinen perusaskel on perustaa vaatimukset käyttäjien suoriutumiseen. Niinhän tässäkin hankinnassa tehdään, mutta siis ei-toimivalla tavalla.
(On muuten hankintailmoituksia - myös Kuntien Tieran julkaisemia - jossa tehdään päinvastoin: käytettävyys on pakollisina mutta ei-valideina vaatimuksina. Yhtä toimimaton ratkaisu.)
Mutta se, miten tämä asia tehdään validisti ja miten vaatimusten saavuttaminen todennetaan, onkin sitten se haaste. Asian vaikeuden osoittaa, että niin tässä kuin käytännössä missään muissakaan Hilmassa julkaistuissa hankintailmoituksissa käytettävyyttä ei ole osattu aidosti edellyttää. Tässä suhteessa tämä hankintailmoitus ei ole muita huonompi mutta ei kyllä parempikaan.   - Olen analysoinut hankintailmoituksia aiemminkin niin tässä blogissa kuin useissa julkaisuissani ja esityksissäni. Ja varmaan teen jatkossakin.
Asiaan ei siis ole helppoja ratkaisuja. Joitakin ratkaisumalleja mielestäni on, mutta niiden raportoinnin aika on, kun ratkaisuista on enemmän empiriaa (esimerkkejä). Itse teen tätä työtä, ja sen lisäksi tätä työtä tehdään jossain määrin Tekesin FlowIT-projektissa, jossa olen myös mukana. En tiedä, onko asian kimpussa muita tahoja; en ole tätä  ainakaan huomannut (en juuri myöskään kansainvälisesti).
Paljon helpompi on kertoa, millä tavoin käytettävyyttä ei tule laittaa tarjouspyyntöihin. Tämä hankintailmoitus on yksi esimerkki; ja muista ei-toimivista tavoista olen kirjoittanut ja pitänyt esityksiä, niin kuin edellä totean.
Yksinkertaisesti ja vähän provokatiivisestikin: älä laita käytettävyyttä ollenkaan tarjouspyyntöön, ellet tiedä oleellisesti parempaa lähestymistapaa kuin se, miten tähän asti käytettävyys on huomioitu tarjouspyynnöissä! Ei pakollisiin vaatimuksiin eikä vertailuperusteisiin.
Niiden miettiminen vie vain turhia resursseja eikä niistä ole viime kädessä mitään hyötyä. Ja itse asiassa ne voivat olla vahingollisia siinä mielessä, että niistä voi tulla väärää mielenrauhaa: ajatellaan, että kun jotakin laittaa, niin sillä olisi jotain positiivista merkitystä. Ja kun ajatellaan kilpailutuksen yleistä logiikkaa, tällaiset toiveet on syytä hylätä alkuunsa.
Lähettänyt Timo Jokela klo 10.04 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
Potilastietojärjestelmää ei "valita" vaan se tulee valituksi tarjouspyynnön vaatimusten ja valintaperusteiden perusteella. Sen vuoksi keskeinen keskustelunaihe pitäisi olla se, mikä on potilastietojärjestelmien tarjouspyynnön sisältö - puhuminen potilastietojärjestelmän "valinnasta" voi antaa väärän kuvan asiasta.
Suomen Telelääketieteen ja e-Health seura (STeHS) ja Sosiaali- ja terveydenhuollon tietojenkäsittely-yhdistys (STTY) järjestävät yhteistyössä Suomen Kuntaliiton sekä hyvinvoinnin klusteriohjelman kanssa seminaarin aiheesta "Mikä on sähköisten potilastietojärjestelmien valintatilanne tänään? - mitä uutta lääkintälaitedirektiivistä?"
Seminaarin tarkemmat tiedot löytyvät täältä.
Ajankohtainen ja mielenkiintoisen oloinen seminaari, johon minäkin aion osallistua.
Mutta yksi huomio ohjelmasta. Seminaarin kahdessa otsikossa puhutaan potilastietojärjestelmän valinnasta:
Onko lääkärillä osaa tai arpaa potilastietojärjestelmien valinnassa? (Tinja Lääveri)
Mikä on sähköisten potilastietojärjestelmien valintatilanne tänään? (Paneeli)
Voi olla, että ohjelmassa on vain kerrottu asiat epätarkasti. Mutta "valinta" on epätarkka ilmaisu ja voi antaa väärän kuvan asiasta. Voi tulla sellainen käsitys, että jokin porukka kävisi älyllisesti läpi eri vaihtoehtoja ja päättäisi sitten järjestelmän valinnasta. Näin asia ei kuitenkaan suoraan etene.
Potilastietojärjestelmää ei "valita" vaan potilastietojärjestelmä tulee valituksi.  Potilastietojärjestelmä kilpailutetaan, ja se tulee valituksi sen perusteella, mitkä ovat tarjouspyynnössä olevat vaatimukset ja valintaperusteet.
Potilastietojärjestelmän "valinta" siis on periaatteessa mekaaninen prosessi sen jälkeen, kun tarjouspyyntö on tehty. Eli tarjouspyyntö on ratkaiseva asia. Keskustelun aihe pitäisi olla, mikä on potilastietojärjestelmän tarjouspyynnön sisältö.
Kuvaavammat yllä mainittujen esitysten otsikot olisivatkin:
Onko lääkärillä osaa tai arpaa potilastietojärjestelmien tarjouspyyntöjen sisällön (pakollisten vaatimusten ja valintaperusteiden) määrittämisessä?
Mikä on sähköisten potilastietojärjestelmien tarjouspyyntöjen sisällön (pakollisten vaatimusten ja valintaperusteiden) tilanne tänään?
Ja erityisen tärkeää potilastietojärjestelmien helppokäyttöisyyden kannalta on keskustella siitä, miten käytettävyys näkyy tarjouspyynnön pakollisissa vaatimuksissa ja valintaperusteissa.
PS. Tuo Tinja Lääverin puheenvuoron otsikko on muutenkin mielenkiintoinen. Toivon vain, että lääkäreille eikä muillekaan käyttäjille anneta väärällä tavalla vastuuttavia osia tai arpoja prosessissa. Käyttäjiä ei pitäisi väärin vastuuttaa tietojärjestelmähankinnoissa eikä siis myöskään järjestelmän valinnan kannalta ratkaisevassa asiassa eli tarjouspyynnön valmistelussa (ks. aihetta käsittelevä juttu).
Lähettänyt Timo Jokela klo 9.29 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
maanantai 29. lokakuuta 2012
Tietotekniikan liitto järjestää ja minä pidän käytettävyyskurssin 12.-13.11.12. Viime keväänä vastaava kurssi oli täynnä, ja kurssista tuli ihan mukavaa palautetta.
Kurssin toinen päivä keskittyy erityisesti siihen, miten käytettävyys olisi otettava huomioon tietojärjestelmien hankinnoissa (ja miten ei...)
Lähettänyt Timo Jokela klo 11.32 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
Tietotekniikan liitto järjestää ja minä pidän käytettävyyskurssin 12.-13.11.12. Viime keväänä vastaava kurssi oli täynnä, ja kurssista tuli ihan mukavaa palautetta.
Lähettänyt Timo Jokela klo 11.30 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
tiistai 23. lokakuuta 2012
Kohtele käyttäjiä eettisesti oikein!
Käyttäjiä on kohdeltava eettisesti oikein järjestelmäkehityksessä: käyttäjiä ei tulisi vastuuttaa suunnitteluratkaisuista eikä laittaa rooleihin, joihin heillä ei ole valmiuksia ja jotka menevät ohi heidän ammatillisen työnkuvansa.
Olen usein kirjoittanut käyttäjien toimivista ja ei-toimivista rooleista järjestelmäkehityksessä eri näkökulmista (ks. linkit alla). Näkökulmani on ollut sisällöllinen: siis mitkä on toimivia ja ei-toimivia käyttäjien rooleja käytettävyyden näkökulmasta.
Yksi näkökulma ja termi, jota en suoraan ole ottanut aiemmin esiin, on eettisyys: miten käyttäjiä tulisi kohdella eettisesti oikein järjestelmäkehityksen aikana. Ja mitkä tavat taas ovat epäeettisiä.
Ja ainakin yleisesti voi sanoa, että käytettävyysnäkökulmasta sisällöllisesti toimimattomat käyttäjien roolit ovat myös käyttäjiä kohtaan epäeettisiä.
En ole huomannut, että eettisyydestä olisi aiemmin juurikaan puhuttu tai kirjoitettu suhteessa käytettävyystyöhön. Otin näkökulman kuitenkin esiin paneelissa Käytettävyys ja käyttäjäkokemus '12 -seminaarissa syyskuussa, jossa keskusteltiin käyttäjien rooleista järjestelmäkehityksessä. (asian esiin ottaminen ei ollut varsinainen suunnitelmani, mutta keskustelu meni vain siihen suuntaan).
Pari omaa havaintoa tilanteista, joissa käyttäjiä ei ole kohdeltu oikein (otin nämä esiin ym. seminaarissa):
Olin mukana eräässä järjestelmähankinnassa. Minua ennen oli jokin konsulttiyritys tehnyt järjestelmämäärittelyä. Koska käytössäni olleissa dokumenteissa ei ollut keskeisiä tarvitsemiani tietoja, olisin halunnut haastatella joitakin käyttäjiä. Minulle annettiin kuitenkin aika ehdoton porttikielto, koska - näin minulle kerrottiin - käyttäjät olivat täysin uupuneet aiemmista haastatteluista.
Toisessa tapauksessa olin mukana terveydenhuollon järjestelmäkehitysprojektissa. Olin sopinut haastattelusta erään osastonhoitajan kanssa. Kun menin haastattelutilanteeseen, hän ei ollutkaan siellä yksin vaan oli kutsunut puolikymmentä kollegaansa. Kun ihmettelin tilannetta, selvisi, että kyse oli hänen aiemmasta kokemuksestaan, että päätöksiä suunnitteluratkaisuista on tehty sen mukaan, mitä haastateltavat olivat sanoneet. Siis hänellä oli pelko, että häntä vastuutetaan mahdollisista suunnitteluratkaisuista, mitä hänen sanomisten perusteella tehdään. Eikä hän yksin halunnut ottaa sitä vastuuta.
Erityisen törkeä esimerkki käyttäjien vastuutuksesta on erään ison tietojärjestelmätoimittajan johtajan näkemys, jossa hän piti käytettävyysongelmien syynnä sitä, että heidän projekteihin ei saada "riittävän osaavia käyttäjiä". Ks. myös aiempi kirjoitukseni.
(Varmuuden vuoksi: järjestelmäprojekteissa on riitettävä se, että käyttäjät ovat osaavia omassa ammatissaan. Jos ja kun sellaisia on mukana - niin kuin varmasti on - niin käytettävyysongelmat ovat yksinomaan suunnittelijapuolen tai järjestelmän valitsijoiden osaamattomuuden syytä, ei käyttäjien).
Tyypillisiä muita esimerkkejä käyttäjien väärästä vastuuttamisesta - ja samalla sisällöllisesti ongelmallisista rooleista - ovat myös tilanteet, jossa käyttöliittymät hyväksytetään käyttäjillä (tai heidän edustajillaan) tai laitetaan käyttäjät pisteyttämään käytettävyys toimittajien esittämien demojen perusteella. Ja mielestäni paljon käytetty co-design sisältää eettisesti ongelmallisia elementtejä - laitetaanhan siinä käyttäjä rooliin, joka ei ole hänen keskeistä ammattitaitoaan eikä työnkuvaansa.
Mitä ovat sitten käyttäjien eettisesti oikeat roolit? Näkemykseni mukaan niitä on kaksi:
- olla oman työnsä asiantuntijoita
- kokeilla "työnsä omaisesti" järjestelmiä tai niiden prototyyppejä
Tästä olen kirjoittanut aiemmin esimerkiksi:
Muita linkkejä aiempiin kirjoituksiini, joissa käsittelen käyttäjien rooleja järjestelmäkehityksessä:
Samoin sivuan asiaa kirjassa "Navigoin oikein käytettävyyden vesillä" ja myös käytettävyyden sudenkuopat -sivulla
Lähettänyt Timo Jokela klo 11.57 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
maanantai 15. lokakuuta 2012
Pieni ristiviittaus Käytettävyysnavigoija-blogiin, jonne kirjoittelen yleisempiä käytettävyysasioita. Mutta tämä kyllä koskee myös hankintoja.
Lähettänyt Timo Jokela klo 19.48 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
(Kirjoitan tosi pitkästä aikaa tähän blogiin - enemmän viime aikaisia kirjoituksia on Hanki käytettävyyttä! -blogissa)
Käytettävyysvaatimusten määrittäminen on käytettävyyden tärkeimpiä mutta samalla haastavimpia  ja epäkypsimpiä osa-alueita. Suomi voisi olla tämän asian osaamisessa eturintamassa.
Osallistuin juuri kahteen peräkkäiseen tapahtumaan Kööpenhaminassa:
Otan esiin tässä yhden keskusteluissa esiin tulleen asian: käytettävyysvaatimusten määrittelyn.
Käytettävyysvaatimusten määrittäminen on käytettävyyden keskeisimpiä osa-alueita. Siinä kun määritetään se, millaista käytettävyyttä kehitettävältä järjestelmältä halutaan. Ilman käytettävyysvaatimuksia esimerkiksi ei voi tietää, onko järjestelmän käytettävyys (riittävän) hyvä vai ei.
Kun olen aiemmin tehnyt aihealueen työtä ja kirjoitellut omia julkaisuja, olen havainnut, että asiaa on todella vähän tutkittu. Nyt noissa tilaisuuksissa tuli vahvistusta tälle havainnolle: käytettävyysvaatimuksiin liittyviä julkaisuja ja tutkimusta oikeasti on hyvin vähän:
TwinTide-kokouksessa oli mukana Gilbert Cockton, brittiläinen HCI-alan professori, usein vieraillut ja tunnettu henkilö myös täällä Suomessa. Ja hän toi esiin, että hänkään ei tiedä juurikaan julkaisuja aiheesta sitten 1980-luvun puolivälin.
i-UxSED -workshopissa norjalainen alan kokenut tutkija Asbjørn Følstad kertoi, että kun hän omaa tutkimustaan varten etsi aihealueen viimeaikaisia julkaisuja, niin ainoat julkaisut, mitä hän löysi, olivat Cocktonin ja minun (ehkä sallitaan tällainen pieni itseni esiin tuominen...)
Mitä tämä tarkoittaa? Ainakin tämä tarkoittaa sitä, että jos aihealueesta ei ole julkaistu, niin asiaa myöskään ei ole voitu opettaa (paitsi ehkä 1980-luvun opein). Ja jos ei ole koulutettu, niin tuskin on myöskään osaamista.
Olen itse käynyt läpi varmaan pari sataa erilaista yritystä määritellä käytettävyysvaatimuksia, mitä julkisissa tarjouspyynnöissä näkyy. Ja kuten olen useammassa julkaisussani ja Hanki käytettävyyttä -blogissa kirjoittanut, eipä vain löydy "oikeita" käytettävyysvaatimuksia.
Eikä kyse näytä olevan pelkästään siitä, että julkiset hankkijat eivät itse osaa määritellä. Tiedän, että ainakin jotkut määrittelyt ovat ulkopuolisten käytettävyysasiantuntijoiden tuottamia. Mutta eivät nämäkään - ainakaan ne, jotka tiedän - ole sen kummempia.
Tässä nyt haastankin arvoisat kollegani: Löytyykö teiltä/ onko teidän tiedossanne esimerkkitapauksia, joissa käytettävyysvaatimutukset on (mielestänne) määritelty "oikein"?
Julkaisujen ja oman empiriani - siis miten olen nähnyt käytettävyyttä yritettävän vaatia tarjouspyynnöissä - perusteella voi tehdä sellaisen johtopäätöksen, että käytettävyysvaatimusten osaamista ei vain ole. Mutta tietenkin voin olla väärässä; enhän voi tietää, mitä kaikkia asioita tapahtuu julkisuudesta piilossa. Eli jos mielestäsi olen tuossa väittämässä hakoteillä, niin kommentoi blogiin (tai ota muuten yhteyttä).
Mutta se mikä tulee mieleen, niin tässä asiassa Suomi voisi olla edelläkävijä. Ja erityisesti edelläkävijä voisi olla julkinen sektori, koska käytettävyysvaatimusten merkitys korostuu erityisesti tarjouspyynnöissä.
Oma positioni asiassa on se, että sekä tutkimuksen että oman empiriani perusteella väitän ymmärtäväni asian haasteellisuuden. Ja minulla on myös perusmalleja, miten tätä asiaa voidaan menetelmällisesti ratkaista. Ja myös jonkin verran empiriaa niiden toimivuudesta. Mutta asian kehittämiseksi tarvitaan lisää caseja. Jos kiinnostaa olla edelläkävijä asioiden kehittäjänä tai asiakkaana, niin ota yhteyttä.
Lähettänyt Timo Jokela klo 19.02 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
tiistai 9. lokakuuta 2012
Myös Nielsen sanoo: Älä laita käyttäjiä katselmoimaan!
Aiemmin kirjoitin siitä, että käyttäjiä ei pitäisi laittaa katselmoimaan käyttöliittymiä (linkki).
Jos joku haluaa tähän vielä lisävahvistusta, niin huomasinpa Jacob Nielsenin* ottavan esiin samaa asiaa Alertboxissaan hieman eri kontekstissa (ko. Nielseni juttu liittyy toiseen aiheeseen, mutta siinä mainitaan myös tämä):
"It's extremely important to note that we always give the test users our (very short) satisfaction questionnaire after they've tried using the design. It's completely invalid to simply show people some screens and ask them how well they like them. If people haven't actually used a user interface to perform realistic tasks, they can't predict how satisfied they'd be when actually using the system. (And real use is what matters, after all, not what people say in a survey.)"
Eli vielä kerran: Kaikki maailman käyttäjät, liittykää yhteen ja kieltäytykää käyttöliittymien katselmoinnneista!
*Jos joku ei tunne, niin Jacob Nielsen on käytettävyyden ehkä tunnetuin guru.
Lähettänyt Timo Jokela klo 9.10 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
torstai 4. lokakuuta 2012
Kaikki maailman käyttäjät, liittykää yhteen ja kieltäytykää käyttäjäraadeista ja käyttöliittymädemojen pisteytyksistä!
Kirjoitin aiemmin jutun "Kaikki maailman käyttäjät, liittykää yhteen ja kieltäytykää käyttäjäraadeista ja käyttöliittymien katselmoinneista!" (31.8.12).
Käyttäjien (tai "käyttäjäraadin") tekemä demojen pisteytys on periaatteessa sama asia, vain eri konteksissa. Ja tuomioni on tälle käytännölle on sama kuin käyttäjien tekemille katselmoinneille: käyttäjien tekemä demojen pisteytys on ehdottomasti ei-suositeltava, epävalidi menettely!
Tätä käytäntöä näkee usein julkisissa tietojärjestelmien tarjouspyynnöissä, joissa valitaan "valmisohjelmistojen*" välillä. Käytettävyys on laitettu tarjouspyynnön yhdeksi arviointiperusteeksi siten, että "käyttäjäraati" laitetaan arvioimaan suunnitteluratkaisut pisteillä.
Perusteet sille, miksi tämä on toimimaton ja vääriä tuloksia antava menettely, ovat kutakuinkin samat kuin miksi käyttäjien ei tulisi tehdä käyttöliittymien katselmointeja (ks. juttu 31.8.).
Lisäksi tässä menettelytavassa on se iso ongelma, että käytettävyys on laitettu valintaperusteiden joukkoon. Jos aidosti halutaan käytettävyttä, se olisi oltava pakollinen vaatimus eikä valintaperuste. Ks. juttu 26.1.12.
Miten pitäisi sitten menetellä? Periaatteessa asia pitäisi mennä seuraavasti:
Käytettävyydelle määritettävä käyttäjän työhön pohjautuvat** validit vähimmäisvaatimukset (= millä kriteereillä käytettävyys on riittävän hyvä käyttäjien työn näkökulmasta)
Tuo kohta 2 on vaativa tehtävä. Oma karkea arvioni on, että sen määrittämiseen kuluu 80% hankinnan käytettävyyden varmistamisresursseista. Eli pääosa käytettävyyteen liittyvästä työstä olisi tehtävä ennen tarjouspyyntöä!
Kyseessä ei ole ihan pikkuhomma. Mutta eipä vaihtoehtokaan ole kummoinen. Niin kuin historia osoittaa, hankintojen tuloksena saadaan niin kovin usein järjestelmiä, joiden kanssa käyttäjät sitten kärsivät.
* Ovat itse asiassa usein ohjelmistoja, jotka konfiguroidaan asiakaskohtaisesti. Käytettävyyden arvioinnin kannalta ISO ero täysin valmisohjelmistoihin
** Käytettävyys = käyttäjän työn tukemista
Lähettänyt Timo Jokela klo 8.27 1 kommentti:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
perjantai 14. syyskuuta 2012
Lakimiehet (-naiset) ymmärtävät hankinta-asioita
Taas sain tukea hankintojen lakiasiantuntijoilta sille, että käytettävyyden (laadun) paikka on tarjouspyyntöjen vähimmäisvaatimukset, ei valintakriteerit
Kävin eilen 13.9. kuntamarkkinoilla. Kuuntelin muun muassa Pilvi Takalan (PTC Services) esityksen hankintojen markkinaoikeuscaseista.
On paljon väärinkäsitystä siinä, miten laatua pitäisi edellyttää tarjouspyynnöissä, jotta sitä oikeasti saadaan.
Pilvi esitti oheisen valaisevan kuvan. Siinä tarjouspyynnön vaatimukset ovat havainnollisesti esitetty kolmessa kategoriassa:
minimum requirements for the company (vähimmäisvaatimukset)
minimum requirements for the work (vähimmäisvaatimukset)
Pointti, joka ei suoraan näy kuvasta mutta tuli esiin keskustelussa on se, että laatu pitäisi pyrkiä sisällyttämään noihin "minimum requirements for the work", ja antaa hinnan ratkaista.
Juuri näin se minunkin mielestäni pitää mennä käytettävyydenkin suhteen (ks. esim. Hesarin vieraskynäni 1.7.12).
Pilvi sanoi, että rajankäynti sen kanssa, mitä laittaa minimi vaatimuksiin ja "award" vaatimuksiin on hienosäätöä  (näin ymmärsin). Itse korostaisin, että käytettävyys - se laatutekijä, jota siis itse edustan - nimenomaan pitää sisällyttää noihin vähimmäisvaatimuksiin, ja antaa hinnan ratkaista. Jonkin verran voi käytettävyyttä voi mahdollisesti laittaa valintakriteereihin, mutta pitäisi ymmärtää, että kyseessä on silloin "ylilaatu" (Pilvin kalvossa Award criteria).
Eli sellaiset tarjouspyynnöt ovat täysin epäloogisia, joissa vertailuperusteissa laatu on luokkaa 65% ja hinta 35%. Sillä tavalla kun ei oikeasti saa laatua välttämättä lainkaan.
Lähettänyt Timo Jokela klo 13.08 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
keskiviikko 12. syyskuuta 2012
Timon kommentti HUSin potilastietojärjestelmähankinnasta Hesarissa 12.9.
Lue juttu Hesarin sivuilta TÄSTÄ!
Lähettänyt Timo Jokela klo 11.15 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
perjantai 31. elokuuta 2012
Kaikki maailman käyttäjät*, liittykää yhteen ja kieltäytykää käyttöliittymien katselmoinneista**!
* Lääkärit, sairaanhoitajat, opettajat, lupakäsittelijät, kuntien/ kaupunkien/ valtion virkamiehet, autokauppiaat, isännöijät, matkasihteerit, palkanlaskijat, työnjohtajat jne. jne. - ketkä tahansa, jotka ovat erilaisten tietojärjestelmien käyttäjiä. Sisältää myös ns. käyttäjien edustajat, usein esimiehiä.
** Yleensä arvioimasta käyttöliittymää, mitä mikä siinä hyvää, mitä pitäisi parantaa, jne. (puhumattakaan sanomasta, onko jonkin järjestelmän käytettävyys riittävän hyvä)
Käyttöliittymäratkaisujen katselmointi ei ole käyttäjien tehtävä vaan suunnittelijoiden tulee ottaa vastuu käyttöliittymäratkaisuista.
Tässä olen taas keskustellut järjestelmätoimittajien ja julkisen tahon edustajien kanssa/ kuunnellut heidän puheitaan.
Ja tämä harhakäsitys on tiukasti vallalla: laitetaan käyttäjät (tai asiakkaan edustajat) katselmoimaan käyttöliittymät.
Väitän, että tämä menettelytapa on yksi keskeisimmistä syistä siihen, miksi tietojärjestelmistä tulee vaikeakäyttöiset. Vaikka kuullostaa käyttäjälähtöiseltä, kyseessä on täysin väärä tapa ottaa käyttäjät mukaan. Mutta tietenkin houkutteleva, koska näin vastuu käytettävyydestä saadaan sälytetyksi käyttäjille ja asiakkaalle.
Miksi näin ei pitäisi menetellä? Tässä blogissa olen kirjoittanut tästä aiemminkin, mutta pääkohtia:
Aluksikin taustana: Käytettävyysalalla ei yksinkertaisesti tunneta käytettävyyden arviointimenetelmää "käyttäjien tekemä katselmointi". Eli tällä menetelmällä ei ole mitään tutkimuksellista perustetta. (Käytettävyyden arviointimenetelmiä on kymmeniä).
Katselmoinnnissa käydään läpi käyttöliittymän suunnitteluratkaisuja. Käyttäjillä ei kuitenkaan ole (yleensä) käyttöliittymäkoulutusta. Käyttöliittymän/ käytettävyyden katselmointi ei onnistu "käyttäjäjärjellä" vaan siihen vaaditaan oma ammattitaitonsa (ja on tosi vaativaa heillekin).
Tämä on epävirallinen havainto, mutta kokemukseni on, että käyttäjät eivät ole järin innostuneita tästä roolistaan. Sinällään ihan loogista, koska he joutuvat (1) laittamaan aikaa asiaan, joka ei ole heidän ydintyötään ja (2) tekemään epämukavaa työtä. Käytännössä päättämään ja ottamaan vastuu asioista, joista eivät voi olla varmoja.
Kaikkiaan on riski, että tällaisten katselmointien tulokset ovat laadultaan kyseenalaiset. Tulokset riippuvat täsmälleen mukana olevien käyttäjien analysoinnista ja jäsentelystä. Ja on siis iso riski, että ne eivät osu kohdalleen.
Lisäksi tässä tapahtuu vastuun vierittämistä järjestelmä kehittäjältä käyttäjille. Jos kehitetyssä järjestelmässä onkin puutteita, syyllisiä ovat helposti käyttäjät, joiden tekemien katselmointien tulosten mukaan järjestelmä on kehitetty (tai valittu).
Miten asia sitten pitäisi hoitaa? Lähtökohtana on kaksi käyttäjille sopivaa roolia:
Käyttäjät ovat oman työnsä asiantuntijoita. Käyttäjiä voi (ja tulee) käyttää hyväksi siinä, että suunnittelijat oppivat ymmärtämään käyttäjien työn.
Käyttäjät voivat olla testihenkilöitä kehitettävien järjestelmien tai niiden prototyyppien käytön kokeilemisessa (Huom! Järjestelmän käyttäminen on ihan eri asia kuin käyttöliittymien katselmointi!)  Ei kuitenkaan niin, että käyttäjät itse arvioisivat vaan niin, että heidän käytön onnistumisensa arvioivat muut.
Nämä käyttäjätiedon lähteet (+ tietenkin yleiset käyttöliittymä teoriat, -standardit ym.) tulee olla järjestelmän (käyttöliittymien) suunnitteluratkaisujen perusta.  Ja vastuu suunnitteluratkaisujen laadusta pitää luonnollisesti olla siellä, missä niitä synnytetään eli suunnittelijoilla. Työnä ei ole helppoa (erityisesti kohta 1), mutta tähän pitäisi pyrkiä ja nähdä asia osana käyttöliittymäsuunnittelijoiden ammattitaitoa. Mielestäni on jopa eettisesti väärin, että vastuu suunnitteluratkaisujen laadusta sälytetään käyttäjille.
Summa summarum (otsikko toistaen): Kaikki maailman käyttäjät, liittykää yhteen ja kieltäytykää käyttöliittymien katselmoinneista!
Lähettänyt Timo Jokela klo 11.47 3 kommenttia:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
torstai 5. heinäkuuta 2012
Sain palautetta vieraskynääni Hesarin mielipidepalstalla 4.7, kirjoittajana Suomen taitohankinta Oy:n toimitusjohtaja Kari Annala. Ohessa linkki kirjoitukseen (koko kirjoitus näkyy valitettavasti vain Hesarin digilehden tilaajille).
Mielestäni Annala ehdottaa niitä asioita, joita tänä päivänä käytetään ja jotka vain eivät toimi. Kirjoitin vastineen Hesariin; katsotaan sitten, julkaistaanko se.
Palaan asiaan joka tapauksessa tarkemmin kesälomien jälkeen.
Lähettänyt Timo Jokela klo 7.53 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
maanantai 2. heinäkuuta 2012
Timon vieraskynä HS 1.7.2012: "Helppokäyttöisyyttä osattava vaatia"
Näin kesäloman alkajaisiksi Hesari julkaisi vieraskynäni:
"Helppokäyttöisyyttä osattava vaatia. Tarjouskilpailussa päädytään liian usein tietojärjestelmään, joka on käyttäjilleen tuskallinen".
Pääset lukemaan koko jutun osoitteesta:
Lähettänyt Timo Jokela klo 12.53 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
maanantai 25. kesäkuuta 2012
Käytettävyys ja käyttäjäkokemus -tapahtuma 19.-20.9.12
Talentum Events järjestää kaksipäiväisen tapahtuman. Tarkempaa tietoa: http://www.talentumevents.fi/tapahtumat/conferences/kaytettavyys+ja+kayttajakokemus+12/a2099213
Lähettänyt Timo Jokela klo 16.40 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
maanantai 28. toukokuuta 2012
Vähän myöhään tämä ilmoitus mutta tule jos ehdit! http://www.sytyke.org/kaytettavyysosy/toiminta
Lähettänyt Timo Jokela klo 19.02 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
torstai 3. toukokuuta 2012
Tarjouspyyntö ratkaisee HUSin uuden potilastietojärjestelmän helppokäyttöisyyden
Käytettävyys tulee määrittää oikealla tavalla tarjouspyyntöön, jos halutaan valita aidosti helppokäyttöinen potilastietojärjestelmä ja oikeasti päästä tavoitteeseen "hoitohenkilökunta voi käyttää enemmän aikaansa hoitotyöhön".
Yle uutisoi viime viikolla HUSin uuden potilastietojärjestelmän kilpailuttamisesta. Jutussa todetaan nykyisistä järjestelmistä, että "suurimmat ongelmat liittyvät järjestelmien käytettävyyteen. Ne ovat moniportaisia ja hankalia. Työntekijä joutuu käyttämään aivan suhteettoman paljon aikaa tietokoneensa kanssa".
Uutisen mukaan ulkomaiset ohjelmistoyritykset ovat tulossa mukaan, kun HUS kilpailuttaa uutta potilastietojärjestelmää.
Ovatko ulkomaiset potilastietojärjestelmät sitten käytettävyydeltään parempia? Mahdollisesti - siitä minulla ei ole tietoa. Mutta vaikka olisivatkin, ei ole itsestään selvää, että "paremman käytettävyyden" järjestelmä tulee valituksi.
Ratkaisevaa on se, miten käytettävyys sisällytetään potilastietojärjestelmän tarjouspyyntöön: miten käytettävyys on huomioitu tarjouspyynnön vähimmäisvaatimuksissa ja vertailukriteereissä.
Julkisessa kilpailutuksessa järjestelmän tarjouspyyntö on ratkaisevassa asemassa. Tarjouspyyntö kun on käytännössä järjestelmän tilausdokumentti: se määrittää, millainen järjestelmä halutaan. Hankkijan tulee valita järjestelmä tarjouspyynnössä määritettyjen vähimmäisvaatimusten ja vertailukriteereiden perusteella.
Historia osoittaa, että käytettävyyttä ei osata määrittää julkisten tietojärjestelmien tarjouspyynnöissä aidoksi vaatimukseksi tai valintakriteeriksi. Sinällään se ei ole ihme, koska käytettävyyden aito vaatiminen on menetelmällisesti haastavaa.  (Näistä olen monessa aiemmassa yhteydessä kirjoittanut, ks. tämän blogin aiemmat kirjoitukset ja julkaisut.)
Miten käytettävyysnäkökulmat sitten olisi sisällytettävä potilastietojärjestelmän tarjouspyyntöön? Jos siis halutaan sellainen järjestelmä, että "hoitohenkilökunta voi käyttää enemmän aikaansa hoitotyöhön", niin kuin jutussa todetaan. Kaksi keskeistä asiaa:
Käytettävyys tulisi sisällyttää mahdollisimman pitkälle vähimmäisvaatimuksiin. Miksi näin? Logiikka on yksinkertainen: jos käytettävyys on pelkästään vertailukriteereissä, niin periaatteessa aina voi tulla valituksi järjestelmä, joka saa käytettävyydestä nolla (0) pistettä. Siis voi tulla valituksi järjestelmä, jonka käytettävyys on "nolla".
Koska käytettävyys tarkoittaa käyttäjien suoriutumista työstään, niin viime kädessä ainoa validi tapa määrittää käytettävyysvaatimukset tulee perustua käyttäjien suoriutumiseen työssään.
Miten määrittää tällaiset käyttäjien työssään suoriutumiseen perustuvat vähimmäisvaatimukset tarjouspyyntöön? Lyhyesti sanottuna: tulee määrittää validit mittarit, mittausinstrumentit ja tavoitetasot. Ja jotta vaatimukset olisivat sisällöllisesti oikeita, vaatimusten määrittämisen perustaksi tarvitaan käyttäjien työn syvällinen jäsentäminen.
Käyttäjien työn syvällinen jäsentäminen on erittäin keskeinen toimenpide, joka kuitenkin käytännössä tehdään hankinnoissa kovin pintapuolisesti. Tämä tulisi tehdä ajoissa, ja sitä varten pitäisi varata resursseja. Ja välttää esimerkiksi sitä suodenkuoppaa, että käyttäjät (tai heidän edustajansa) laitetaan itse tekemään työnsä jäsennys.
- Tämän jutun puitteissa näiden asioiden seikkaperäinen kuvaus ei ole mahdollista.  Tarkempaa tietoa saa - kysymällä minulta.
Lähettänyt Timo Jokela klo 10.27 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
tiistai 10. huhtikuuta 2012
Kokemuksia "Käytettävyys tietojärjestelmien hankinnoissa" -kurssista
Pidin ensimmäisen "Käytettävyys järjestelmien hankinnoissa" -kurssin maaliskuussa, http://www.ttlry.fi/koulutus/kaytettavyyden-varmistaminen-hankinnoissa-1232012.
Kurssin keskeinen sisältö oli esittää ratkaisuja sille, miten käytettävyys saataisiin aidosti mukaan tietojärjestelmien tarjouspyyntöihin: miten laatia todennettavia ja valideja käytettävyysvaatimuksia.
Kurssi oli täysi, 12 osallistujaa. Kaikki halukkaat eivät päässeet mukaan. Luultavasti 12 on sopiva maksimi määrä tällaiselle ryhmätyöintensiiviselle kurssille.
Sekä oman tuntuman että kurssilaisten palautteen perusteella kurssi meni ihan kohtullisesti. Varsinkin ottaen huomioon, että kurssi oli ensimmäinen laatuaan. Mutta parannettavaakin löytyi. Itse tiivistäisin palautteet ja oppimat seuraavasti:
Aihe koettiin kiinnostavaksi ja harjoitukset ja case hyviksi, sekä kouluttaja asiantuntevaksi...;)
Yksi päivä ei riitä tällaiseen sisältöön; mennään kuitenkin sekä käytettävyyden että hankintojen "syvällisyyksiin". Ehkä seuraavalla kerralla niin, että kaksi kurssipäivää; ehkä kaksi erillistä kurssia
Palataan asiaan uudestaan syksyllä!
"käytettävyysopit hyviä & kiinnostavia"
"ajatuksia ja ideoita siitä, miten käytettävyyttä voitaisiin ylipäätään parantaa"
"kouluttaja käytettävyyden huippuasiantuntija", "erittäin hyvä asiantuntemus"
"päivä avasi käytettävyyteen liittyvää problematiikkaa", "tuli selväksi, että asia on vaikea"
"harjoitukset olivat hyviä, sitä kautta asiat konkretisoituivat"
"kouluttajalla oli selvästi paljon enemmän asiaa kuin päivään mahtui, joten jonkunlainen jäsentely tulee varmaan tapahtumaan"
"kouluttajan tapa esiintyä oli hieman pomppiva", "poukkoileva esitystapa", "sujuvampi esitystapa"
"harjoitusten toteutus vaatii vielä kehittämistä"
"paljon asiaa, vähän aikaa"
Lähettänyt Timo Jokela klo 11.58 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
Uudemmat tekstit Vanhemmat tekstit Etusivu
Positiivinen SUS (System Usability Scale) suomeksi
Positiivisen SUS -skaalan on todettu antavan yhtä luotettavia tuloksia kuin perinteisen SUS -skaalan, mutta on helpompi täyttää (ja sitä kau...
Millaista on käytettävyysasiantuntijan työ Logicalla, Tiedolla ym?
("ym." otsikossa tarkoittaa yleensäkin julkiselle taholle, esimerkiksi terveydenhuollolle, järjestelmiä kehittäviä ja toimittavia ...
P-SUS (positiviinen SUS) -kysely suomeksi: uusi versio
Aiemmassa kirjoituksessani ehdotin käännöstä P-SUS (Positive System Usability Scale) -kyselylle, ja pyysin käännöksestäni palautetta. Ja kii...
Yksi vaikeakäyttöinen järjestelmä lisää kouluihin?
Kohtele käyttäjiä eettisesti oikein!
Myös Nielsen sanoo: Älä laita käyttäjiä katselmoim...
Kaikki maailman käyttäjät, liittykää yhteen ja kie...
Lakimiehet (-naiset) ymmärtävät hankinta-asioita
Timon kommentti HUSin potilastietojärjestelmähanki...
Kaikki maailman käyttäjät*, liittykää yhteen ja ki...
Timon vieraskynä HS 1.7.2012: "Helppokäyttöisyyttä...
Käytettävyys ja käyttäjäkokemus -tapahtuma 19.-20....
Tarjouspyyntö ratkaisee HUSin uuden potilastietojä...
Kokemuksia "Käytettävyys tietojärjestelmien hankin...
Käytettävyyssuunnittelun perusteet. Sähköisenä tai painettuna
Olen ollut käytettävyyden ja käyttäjäkokemuksen suunnittelun alalla 1990-luvun puolesta välistä lähtien käytännön asiantuntijana, tutkijana, opettajana ja hankkeiden johtajana. Olen vienyt käytäntöön, kehittänyt uusia lähestymistapoja ja alan standardeja. Viime aikoina olen keskittynyt erityisesti käytettävyyden varmistamiseen tietojärjestelmien hankinnoissa. Olen kansainvälisestikin ensimmäisiä, joka on tunnistanut alan erityisen haastavaksi käytettävyyden osa-alueeksi. Olen auttanut asiakkaita tällä osa-alueella ja samalla kehittänyt tähän haasteeseen uusia lähestymistapoja: menetelmän, jolla pystyy määrittämään todennettavat ja validit käytettävyysvaatimukset tarjouspyyntöihin sekä käyttäjätutkimusmenetelmän, jolla pystyy nopeasti analysoimaan käyttäjien työn syvällisemmin kuin paljon resursseja vaativilla käyttötapausmäärittelyillä ym. Olen julkaissut aiheesta alan kansainvälisillä foorumeilla.
Teema: Yksinkertainen. Sisällön tarjoaa Blogger.