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 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 eo cs fi fi fi fi fi fi cs 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 cs fi fi fi fi fi fi nb fi fi it fi fi en fi fi fi
Esimerkki käytettävyysvaatimuksesta, joka ei toimi
Kun tämä vaatimus osui silmään ja liittyy aiempaan keskusteluaiheeseen, niin piti vielä laittaa tämä viesti ennen pikku lomalle lähtöä
Tässä tarjouspyynnössä pisteytetään toimittajan tarjousta "käytettävyyden kehittämisen menetelmien ja prosessien" perusteella.
Tässä on siis aluksikin se ongelma, että prosessit eivät takaa käytettävyyttä.
Mutta toinen ja mielenkiintoisempi ongelma on se, että vaatimuksessa ei määritellä, millä kriteereillä pisteytys tehdään. Miten pisteyttää "käytettävyyden kehittämisen menetelmät ja prosessit"? Kuka on tällaiseen arviointiin pätevä, ja mihin malliin perustuen tällainen arviointi tehdään?
Ajatellaan, että toimittajalla on käytettävyysammattilainen, joka kuvaa käytettävyysprosessin. Ja sitten tilaajan käyttämä käytettävyysammattilainen arvioi suunnitelman, ja näkee siinä puutteita. Kysymys on, että millä perusteella tilaajan käytettävyysammattilaisen arviointi on pätevä? Eikö yhtä hyvin voikin olla niin, että toimittajan suunnitelma onkin hyvä, mutta tilaajan ammattilainen tekikin väärän arvion?
Itse olen tehnyt tällaisia arviointeja, ja mielestäni pystyn tekemään perusteltuja arviointeja jopa useammalla menetelmällä (kun olen aiheesta väitellyt). Mutta samalla totean, että joku toinen voi asettaa tekemäni arvioinnin kiistanalaiseksi (tai ainakin yrittää...;).  Tai sitten toisinpäin. Joka tapauksessa, kovin ongelmallinen tarjouspyynnön arviointikriteeri.
Ja itse asiassa kolmas ongelma: valituksi voi tulla toimittaja, jolla ei ole minkään tasoisia käytettävyysprosesseja (jos saa muista kriteereistä paljon pisteitä).
Lähettänyt Timo Jokela klo 16.46 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
Käyttäjälähtöisyyden vaatiminen ei takaa käytettävyyttä
Edellisen kirjoituksen kommentissa kerrottiin tarjouspyynnöstä, jossa edellytettiin: "....toimittajan tuli suunnitella käyttäjälähtöisesti..."
Kuitenkaan tällaiset prosessivaatimukset - vaaditaan toimittajalta käyttäjälähtöistä suunnittelua, käytettävyystestausta jne. - eivät ole valideja käytettävyysvaatimuksia. Niillä ei periaatteessa taata minkään tason käytettävyyttä.
Prosessivaatimukset voi täyttää, vaikka tulosten laatu on mitä sattuu. Ne eivät erottele toimittajan kykyä tuottaa laatua. Toki laatua voi toteutua, mutta yhtä hyvin se voi jäädä toteutumatta.  Prosessivaatimuksilla taataan käytännössä ainoastaan se, että jotain tehdään (ja lisäkustannuksia asiakkaalle).
Sitten on ihan eri asia, että käytettävyyden aikaansaamiseksi käytännössä tarvitaan systematiikkaa ja prosesseja. Mutta syy-seuraus -suhteet siis eivät mene niin, että systematiikalla ja prosesseilla (tai menetelmillä) taattaisiin mitään.
Lähettänyt Timo Jokela klo 7.05 2 kommenttia:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
torstai 28. huhtikuuta 2011
Mikä mahtaa olla käytettävyystestien laatu Suomessa?
Jatkona edelliseen: Ralf Molich kirjoitti sähköpostissaan seuraavan kokemuksensa (lupasi, että saan julkaista sen blogissani):
"During the past 1-2 years I have been asked to carry out QA checks on 7 usability test providers. QA checks were ordered by clients who wanted uniform and state-of-the art usability tests across countries, including countries whose language they did not understand. They also wanted to be sure that they got what they paid for so they could safely make important decisions based on the usability test results. Needless  to say, almost all the people involved in these tests had impressive portfolios and exams from renowned universities.
The findings were, eh, interesting. Only one utest provider passed without serious notes. Six of seven got one or more serious or critical notes on their adherence to standard procedures for usability testing."
Eli Molichin havainto on, että käytettävyystestien tekemisen laatu on kyseenalaista. Vaikka niiden tekijöillä on meriittejä.
Minulla on tullut se käsitys, että tilanne Suomessa ei ehkä ole sen kummempi. Sen perusteella, mitä olen kuullut kentältä ja mitä käytettävyysraportteja olen itse joskus nähnyt.
Vai mitä kokemuksia on itse kullakin?
Lähettänyt Timo Jokela klo 9.24 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
keskiviikko 20. huhtikuuta 2011
Käytettävyyttä ei vaadita kilpailutuksissa
Oulun yliopistossa vasta tehdyssä tutkimuksessa käytiin läpi julkisia tietojärjestelmien tarjouspyyntöjä, kaikkiaan 38 kappaletta. Tuloksena oli, että useassa tarjouspyynnössä kyllä yritettiin vaatia käytettävyyttä: 29 tarjouspyynnössä käytettävyys oli esillä vaatimuksena jollakin tavalla.  Kuitenkaan ei löytynyt yhtään tarjouspyyntöä, jossa olisi aidosti vaadittu käytettävyyttä. http://www.yourhost.is/images/stories/NordiCHI2010/accepted/281.html
Mitä tarkoittaa aito käytettävyysvaatimus? Sen olisi aluksikin oltava muodollisesti vaatimus. Lisäksi sen tulisi sisällöllisesti määrittää sovelluksen järkevää käytettävyyttä. Tarkemmin sanottuna:
Vaatimusten tulisi olla todennettavia: vaatimuksen täyttyminen tulisi pystyä tarkistamaan niin, että ei ole erimielisyyksiä vaatimuksen toteutumisesta.
Vaatimusten tulisi olla valideja: vaatimus on sisällöltään oikea (= vaatimusten toteutuminen tarkoittaa oikeasti käytettävyyttä)
Lisäksi vaatimusten tulisi olla kattavat: niiden tulisi määrittää järjestelmän käytettävyys riittävästi eri näkökulmista
Nämä ehdot täyttäviä  vaatimuksia ei löytynyt läpikäydyissä tarjouspyynnöissä. Eikä ole löytynyt sen jälkeenkään - olen pyrkinyt seuraamaan säännöllisesti uusia tarjouspyyntöjä.
Aitojen käytettävyysvaatimusten määrittäminen on oikeasti haastavaa. Seuraavissa postauksissa käyn läpi asiaa esimerkkien kautta.
Lähettänyt Timo Jokela klo 15.49 2 kommenttia:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
tiistai 19. huhtikuuta 2011
Muutoshallinta: käytettävyysongelmien vastuun vierityksen kulminaatiopiste
Tyypillisessä asiakaskohtaisen järjestelmän kehitysprosessissa tapahtuu seuraavaa (kuva):
Toimittaja (käyttöliittymäsuunnittelija) suunnittelee käyttöliittymäratkaisuja (rautalankamalleja ym), perustuen vaatimusmäärittelyihin ja muihin asiakkaalta saamiin tietoihin
Toimittajan ehdotus käydään läpi projektin ohjausryhmässä tai vastaavassa, jossa suunnitelma hyväksytään. Toimittaja voi suostua pieniin muutosehdotuksiin, mutta ei isoihin.
Tämän jälkeen suunnitteluratkaisu laitetaan muutoshallintaan. Käytännössä tämä tarkoittaa sitä, että jos käyttöliittymää halutaan muuttaa, se tarkoittaa lisätilausta.
Tässäpä sitä ollaan. Kun asiakas hyväksyy suunnitelman, niin samalla tapahtuu vastuun siirto käyttöliittymän laadusta asiakkaalle. Käyttöliittymän laitto muutoshallintaan on helpotus toimittajalle, mutta tarkoittaa haasteita asiakkaalle, jos käyttöliittymä ei toimikaan.
Toisella tavalla sanottuna: Voidaan puhua asiakas- ja käyttäjälähtöisyydestä. Sitä se onkin tietenkin jossain määrin. Mutta käytännössä oleellista on vastuun siirtäminen asiakkaalle.
Lähettänyt Timo Jokela klo 8.32 2 kommenttia:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
Se dramaattinen ero: käytettävyys hankinnoissa vs. tuotekehityksessä
Käytettävyyden varmistus hankinnoissa ja tuotekehityksessä eroaa draamaattisesti toisistaan. Tässä en kuitenkaan tarkoita käytettävyyden varmistuksen perusasioista: menetelmiä ja prosesseja. Vaan vastuun jakoa: kuka maksaa, jos käytettävyys menee pieleen?
Tuotekehityksessä vastuun käytettävyydestä kantaa yritys itse ("suunnittelija"). Jos käytettävyys ei pelitä, niin se näkyy yrityksen menestyksessä. Rahat menevät kilpailijoille (kuvan yläosa). Hyvä esimerkki tästä Nokian "käytettävyyskohtalo".
Hankinnoissa vastuu käytettävyysongelmista on kuitenkin ASIAKKAALLA - eikä suunnittelijalla (täysin epäloogista näin entisen tuotekehittelijän taustalta - kesti aikansa ennenkuin sen opin). Mutta näin se on: jos halutaan korjata toimittajan suunnitteleman käyttöliittymän ongelmia, niin se tarkoittaa asiakkaan tekemää lisätilausta toimittajalle. Eli raha siirtyy täysin päinvastoin kuin tuotekehityksessä. Kuvan alaosa.
Hankinnoissa käytettävyysongelmat jäävät asiakkaan harmiksi. Ja jos niitä korjataan, se tarkoittaa lisäkustannuksia asiakkaalle. Ja lisäbisnestä toimittajalle - käyttöliittymän suunnittelijalle.
Seuraavassa postauksessa tarkastelen vähän tarkemmin tätä mekanismia.
Lähettänyt Timo Jokela klo 7.08 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
maanantai 18. huhtikuuta 2011
Onko tämä dialogi? Tyypillinen esimerkki julkisen järjestelmän käytettävyysongelmasta
Esimerkkejä "epäkäytettävyyden" kukkasista on vaikka kuinka. Tässä valitsen vasta eteeni tulleen esimerkin.
Tuli oikein aito perinteinen posti Valtiokonttorilta, jossa kehotetaan siirtymään verkkolaskutukseen ja annetaan toistaiseksi voimassa oleva ilmainen palvelu.
Ei liene yllätys, että homma ei onnistunut - ainakaan minulta. Tällä hetkellä on selvityksen alla, että onko kyseessä tekninen ongelma vai mikä.
Joka tapauksessa, rekisteröitymislomakkeessa on mielenkiintoinen kenttä, joka ei näytä yhtään dialogilta (rengastettu kuvassa). Kuitenkin se on merkitty punaisella tähdellä, eli pakollinen täyttää.
Miten sinä tulkitsisit tuon kentän? (vihje: kyllä se on dialogi...)
- Mutta pointti on että vastuu tällaisista käytettävyysongelmista on tietojärjestelmän hankkijalla, ei toimittajalla.  Tämä onkin koko tämän blogin keskeinen perussanoma: miten hankkija voi aidosti toimia käytettävyyden varmistamiseksi (ilman että jää tällaisia ongelmia, tai että tilaa korjauksia kalliilla muutostilauksilla)
Lähettänyt Timo Jokela klo 10.35 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
sunnuntai 17. huhtikuuta 2011
Käytettävyystyö ei ole rutiinia
Käytettävyystyö ei ole rutiinia. Käytettävyyttä ei varmisteta käyttäjäkeskeisillä prosesseilla tai menetelmillä: ei käytettävyystestauksella, käyttäjätutkimuksilla, käyttötapausmäärittelyillä, käytettävyysohjeistoilla.
Asiaa on tutkittu tieteellisesti Rolf Molichin vetämissä CUE -tutkimukset: http://www.dialogdesign.dk/CUE.html. Yksi tulos vaikkapa se, että kun yhdeksän (9) käytettävyystestiryhmää testasi samaa kohdetta, niin 75% raportoiduista ongelmista löysi vain yksi ryhmä.
Voidaan ajatella ja usein sanotaankin, että käytettävyys on nuorehko ja ei vielä kyspä tieteen ala. Ja sitä kautta nähdään selitys tällaisille tutkimustuloksille.
Itse kuitenkin olen taipuvainen ajattelemaan, että pointti on se, että käytettävyys on olennaisesti "älytyötä". Käytettävyystyöhön liittyy vain vähän rutiiniasioita. Näitä ovat ehkä sellaiset kuin käyttäjien rekrytointi, käytettävyystestien logistiset järjestelyt ja perusrutiinit.
Mutta käytettävyyden varsinaisen substanssin laatua eivät mitkään menetelmät takaa. Molichin tutkimuksessa todettiin, että käytettävyystestien tulokset olivat ihan erilaiset riippuen siitä kuka testejä sattui tekemään. Väitän, että vielä suurempi hajonta on tilanteessa, jossa pitäisi valita sopivia käytettävyystoimenpiteitä tiettyyn projektikontekstiin. Ja erityisesti väitän, että aivan liian yleisesti valitaan "oikeaksi" toimenpiteeksi käytettävyystestaus.
Lähettänyt Timo Jokela klo 19.47 Ei kommentteja:
Kohteen lähettäminen sähköpostitseBloggaa tästä!Jaa TwitteriinJaa FacebookiinJaa Pinterestiin
Käytettävyyden varmistus ei ole rutiinia
Käytettävyyden varmistus ei ole rutiinia. Käytettävyyttä ei varmisteta käyttäjäkeskeisillä prosesseilla tai menetelmillä: ei käytettävyystestauksella, käyttäjätutkimuksilla, käyttötapausmäärittelyillä, käytettävyysohjeistoilla.
Asiaa on tutkittu tieteellisesti, esimerkiksi Rolf Molichin vetämät CUE -tutkimukset: http://www.dialogdesign.dk/CUE.html
Esimerkiksi voi mielestäni ottaa vaikka tapaus Nokian. Nokia on aktiivinen käytettävyys- ja käyttäjäkokemuskentällä: mukana alan konferensseissa, yrityksessä on alan tunnettuja asiantuntijoita, useita alan tohtoreita, yrityksessä on sovellettu ja kehitetty käytettävyysalan menetelmiä. Siltikin Nokian "käyttöliittymäkohtalo" oli mitä oli (miksi näin - se ei ole tämän blogin aihe).
Käyttäjäkeskeisyyttä, käytettävyysprosesseja ja menetelmiä vaatimalla ei varmisteta käytettävyyttä. Se, miten käytettävyyden varmistusta voi tehdä ja erityisesti tietojärjestelmien hankinnoissa, on tämän blogin aihe.
Lähettänyt Timo Jokela klo 19.47 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...
Esimerkki käytettävyysvaatimuksesta, joka ei toimi
Käyttäjälähtöisyyden vaatiminen ei takaa käytettäv...
Mikä mahtaa olla käytettävyystestien laatu Suomessa?
Käytettävyyttä ei vaadita kilpailutuksissa
Muutoshallinta: käytettävyysongelmien vastuun vier...
Se dramaattinen ero: käytettävyys hankinnoissa vs....
Onko tämä dialogi? Tyypillinen esimerkki julkisen ...
Käytettävyystyö ei ole rutiinia
Käytettävyyden varmistus ei ole rutiinia
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.