Hanki käytettävyyttä!

Erään tarjouspyynnön käytettävyysanatomia, osa 1: Vähimmäisvaatimukset

2012-02-28T09:17:00.000+02:00

Tämän tarkasteltun kohteena olevassa tarjouspyynnössä on määritetty käytettävyyteen liittyviä vähimmäisvaatimuksia (1) asiantuntijoille, (2) palvelulle ja (3) kehitysprosessille. Positiivista on, että käytettävyyteen on kiinnitetty monipuolisesti huomiota. Kuitenkin vähimmäisvaatimuksissa on merkittäviä puutteita sekä todennettavuuden että validiuden näkökulmasta. Yhteenvetona on vaikea nähdä, miten näillä vaatimuksilla on merkittävyyttä käytettävyyden saavuttamisen näkökulmasta.

Toisaalta, kuten blogia seuranneet tietävät, käytettävyyden vaatiminen on aidosti haastavaa, eikä hyviä esimerkkejä juuri löydy.

(Osassa 2 tarkastellaan tarjouspyynnön vertailuperusteita)

----------------------------------------

Tarkastelun kohteena on Oikeushallinnon tietotekniikkakeskuksen tarjouspyyntö aloitepalvelun kehittämisestä. Ja siinä erityisesti se, miten käytettävyys on huomioitu.

Tämän analyysin tausta on se, että Teemu Ropponen tietotekniikkakeskuksesta "haastoi" minua arvioimaan tätä tarjouspyyntöä. Mikä on hieno asia, ja tekee toivottavasti lukijallekin asiasta mielenkiintoisemman ja konkreettisen; tarjouspyyntöhän on vielä julkisesti saatavilla. Aiemmin blogissani olen ottanut esimerkkejä anonyymisti (vaikka lukijoilla tietenkin on periaatteessa ollut mahdollisuus jäljittää alkuperäinen lähde).

Tarjouspyynnössä on tavanomaiseen tapaan määritetty:

vähimmäisvaatimukset: vaatimukset, jotka tarjoajan on täytettävä, jotta olisi mukana kilpailussa
vertailuperusteet: näin perusteella valitaan voittava tarjous niiden joukosta, jotka täyttävät pakolliset vaatimuksen

Tässä kirjoituksessa ("osa 1") tarkastellaan sitä, miten käytettävyys näkyy vähimmäisvaatimuksissa. Omasta mielestäni vähimmäisvaatimukset on se "tärkeämpi" osa, koska valituksi voi periaatteessa tulla sellainen toimittaja, joka pelkästään täyttää nämä vähimmäisvaatimukset (ks. myös: http://hankikaytettavyytta.blogspot.com/2012/01/laatu-pakollisiin-vaatimuksiin-eika.html)

Mitä tarjouspyynnön vähimmäisvaatimuksiin on kirjoitettu käytettävyydestä

Löysin tarjouspyynnöstä seuraavia vähimmäisvaatimuksia:

1. Asiantuntijoihin liittyvät vähimmäisvaatimukset

Edellytetään käytettävyysasiantuntijaa/ käyttöliittymäsuunnittelijaa, jolla "tulee olla vastaavasta tehtävästä vähintään kolmen vuoden kokemus… vuorovaikutteisen verkkopalvelun rakentamisesta". Kyseisellä palvelulla on oltava "vähintään 500 keskimääräistä käyttäjää päivässä ja vähintään 2 käyttökieltä".

2. Palveluun liittyvät vähimmäisvaatimukset:
Toimittajan tulee sitoutua noudattamaan "liitteen 7 mukaisen palvelun". Ja liitteestä 7 löysin seuraavat palvelun käytettävyyteen liittyvät vaatimukset:

Näistä seikoista johtuen järjestelmän käyttöliittymän on täytettävä vähintään julkisille sähköisille palveluille asetetut yleiset käytettävyys- ja saavutettavuusvaatimukset.
Koska kyseessä on verkkopalvelu, jota käyttää lukuisa määrä satunnaisia käyttäjiä (aloitteen tekijät), on se suunniteltava helppokäyttöiseksi. Järjestelmän tulee olla mahdollisimman käyttäjäystävällinen, jotta se kannustaisi käyttäjiä sähköisten palveluiden käyttämiseen ja positiivisen kokemuksen saamiseen.
Helppokäyttöisyys (huom. PETOn käytettävyysvaatimukset) sekä kansalaiselle että viranomaiselle
Järjestelmä on rakennettava siten, että kannatusilmoitusten keräämisen käsittelysääntöjä on helppo muuttaa tarvittaessa (esim. on mahdollista että jossain vaiheessa kannatusilmoitusten keräämisen käynnistys muuttuu siten, että aloitteelle kerätään ensin OM:n verkkopalvelussa 50 kannatusilmoitusta, ja aloite tulee vasta sen jälkeen tarkistettavaksi OM:ään)
Järjestelmän on tuettava aloitteen vireillepanijaa eri tyyppisten aloitteiden tekemisessä (ohjeet, pakolliset tiedot)
Järjestelmän käyttäjän pitää aina tietää, missä hän on ja mitä hän voi siinä tehdä.

3. Kehitysprosessiin liittyvät vähimmäisvaatimukset:
Liitteestä 7 löysin seuraavat kehitysprosessiin liittyvät vaatimukset:

Toimittaja on tehnyt järjestelmälle käytettävyys- ja suorituskykytestit vaatimusmäärittelyjen mukaisesti.
Järjestelmälle on voitava tehdä käytettävyystestaus kolmannen osapuolen toimesta ennen tuotantoonottoa.

Vaatimusten arviointia

Tarkastelen vaatimuksia kahdesta näkökulmasta:

todennettavuus: onko vaatimus määritetty siten, että sen täyttyminen voidaan tarkistaa niin, että ei tule erimielisyyksiä siitä, toteutuuko vaatimus vai ei (itse asiassa, josa vaatimus ei ole todennetava, niin se ei käytännössä ole vaatimus ensinkään)
validius: onko vaatimus on sisällöllisesti oikea (= sen täyttyminen tarkoittaa, että sillä on aidosti vaikuttavuutta järjestelmän parempaan käytettävyyteen)

1. Henkilöihin liittyvät vähimmäisvaatimukset

Vaatimus ("... vähintään kolmen vuoden kokemus...) on kohtuullisesti todennettavissa
Mutta vaatimuksen validius on ongelmallinen: käyttöliittymä-/ käytettävyyskokemus kun sinällään ei takaa viime kädessä aitoa käyttöliittymäsuunnittelun tai käytettävyyden ammattitaitoa. Käyttöliittymiä ja myös käytettävyysaktiviteetteja kun on voinut suorittaa ilman mitään alan koulutusta. Minun on myöskään vaikea nähdä, miten vaatimus "vähintään 500 käyttäjää" on relevantti käytettävyysasiantuntijan näkökulmasta?

Eli käytännössä tämä vähimmäisvaatimus ei edellytä ammattitaitoista käytettävyys-/ käyttöliittymäsuunnittelijaa.

2. Palveluun liittyvät vähimmäisvaatimukset

"... täytettävä vähintään julkisille sähköisille palveluille asetetut yleiset käytettävyys-.... vaatimukset". Tässä ei suoraan määritetä, mitä nuo vaatimukset ovat; ehkä JHS-suosituksiin?
Joka tapauksessa, tämän tyyppisessä vaatimuksessa on kaksi ongelmaa. (1) Useimmat JHS-suositusten yksittäisistä vaatimuksista ovat luonteeltaan ei-todennettavia. (2) Tällaiset yleiset vaatimukset - vakka olisivatkin todennettavia - yleensäkään eivät kata käytettävyydestä kuin ehkä 10 - 20%.
"... on se suunniteltava helppokäyttöiseksi. Järjestelmän tulee olla mahdollisimman käyttäjäystävällinen", "helppokäyttöisyys.... sekä kansalaiselle että viranomaiselle", "käsittelysääntöjä on helppo muuttaa", "järjestelmän on tuettava aloitteen vireillepanijaa", "käyttäjän pitää aina tietää, missä hän on ja mitä hän voi siinä tehdä". Tällä tavalla muotoillut "pyöreät" vaatimukset eivät ole todennettavia eivätkä siten varsinaisia vaatimuksia.

3. Kehitysprosessiin
liittyvät vähimmäisvaatimukset

"Toimittaja on tehnyt järjestelmälle käytettävyys- ja suorituskykytestit vaatimusmäärittelyjen mukaisesti." Aluksikaan, en löytänyt noita käytettävyystestimäärittelyjä tarjouspyynnöstä. Mutta vaikka siellä sellaiset vaatimukset olisikin, niin niin käytettävyystestit sinällään eivät takaa mitään käytettävyydestä, toisin sanoen, niiden edellyttäminen ei ole validi vaatimus (tähän on montakin syytä, yksi esimerkiksi CUE-tutkimusten tulokset, ks. http://hankikaytettavyytta.blogspot.com/2011/04/lahtokohta-kaytettavyyden-varmistus-ei.html).

"Järjestelmälle on voitava tehdä käytettävyystestaus kolmannen osapuolen toimesta ennen tuotantoonottoa". No, tätä ei oikein tulkitse vaatimukseksi ollenkaan, koska sen voi jokainen toteuttaa. Käytettävyystestaustahan on mahdollista tehdä hyvinkin keskeneräisellä järjestelmällä, jopa paperitasolla.

----------------

Yhteenveto: ks. tiivistelmä ylhäällä.

"Usability in Government Systems" jo myynnissä

2012-02-09T08:53:00.002+02:00

Tuleva kirja Usability in Government Systems jo Amazonin etukäteismyynnissä. Sisältää mm. Elizabeth Buien ja Timon kirjoittaman kappaleen "Getting UX into the contract".

http://www.amazon.com/gp/product/0123910633

Laatu pakollisiin vaatimuksiin eikä valintakriteereihin tarjouspyynnöissä

2012-01-26T12:02:00.002+02:00

Laatu olisi sisällytettävä tarjouspyynnöissä ensi sijaisesti pakollisiin vaatimuksiin. Valintakriteereissä voi olla mukana "ylimääräinen" laatu, mutta sen painoarvon ei tulisi olla kovin korkea.

-------------------
Aluksikin: tämä juttu on tietojärjestelmien (julkisesta) kilpailutuksesta yleensä, ei mitenkään erityisesti käytettävyydestä. Mutta pätee tietenkin käytettävyyteenkin - kun käytettävyys on yksi laatutekijä.

Miten kilpailuttaa ja tehdä tarjouspyyntö, että saataisiin tulokseksi laatua?

Laatu (esimerkiksi käytettävyys) voi näkyä kahdella tavalla tarjouspyynnössä: (1) pakollinen vaatimus, jonka täyttämiseen jokaisessa tarjouksesssa on sitouduttava ja (2) valintakriteeri, jolloin toimittaja saa sitä enemmän pisteitä, mitä parempaa laatua pystyy tarjoamaan (eniten pisteitä saanut tarjous on valittava).

On esitetty, että laadulla pitäisi olla painoarvoa valintakriteereissä. Eräskin ohjelmistotalo on ottanut lähtökohdaksi, että he eivät lähde mukaan kilpailutuksiin, jossa hinnan osuus on yli 40% valintakriteereistä.

Miten tämä nyt oikein menee? Miten laatu pitäisi laittaa pakollisiksi vaatimuksiksi ja valintakriteereiksi?

PAKOLLISET VAATIMUKSET

Loogista on määrittää laatu pakollisiin vaatimuksiin niin, että niiden täyttäminen riittää "riittävän" hyvään järjestelmään. Toisin sanoen, vaikka toimittaja ei saisi yhtään laatupisteitä valintakriteereistä, niin sen tuottama laatu pitäisi olla riittävää.

Otetaanpa esimerkki. Ajatellaan, että tarjouspyynnön valintakriteereissä laadun painoarvo on 50% ja hinnan 50%. Ajatellaan edelleen, että saadaan kolme tarjousta, joista yksikään ei saa yhtään laatupistettä. Tällöin tulee kuitenkin valita yksi näistä (joka siis on halvin).

Mutta tässäkin tapauksessa tietenkin tuon valitun järjestelmän olisi oltava "riittävän" hyvä asiakkaan tarpeisiin.

Mielestäni ei ole muuta loogista johtopäätöstä kuin tuo edellä mainittu: pakolliset vaatimukset tulee määrittää siten, että niiden täyttyminen takaa riittävän hyvän järjestelmän.

VALINTAKRITEERIT

Mikä on sitten laadun osuus valintakriteereissä? Jos kerran pakollisilla vaatimuksilla saavutetaan riittävän hyvää, niin tästähän seuraa loogisesti, että pisteytettävä laatu on ylimääräistä laatua. Eli asiakas saa jotain parempaa kuin mitä välttämättä tarvitsee.

Tästä loogisesti seuraa se, että järkevä laadun osuus valintakriteereissä ei voi olla kovin korkea. Otetaan esimerkiksi lähtökohta, että valintakriteereissä laadun osuus on 50% ja hinnan osuus 50%. Mitä tämä merkitsee käytännössä? Ääri tapauksessahan tämä tarkoittaa, että jos kilpailijat eivät pärjää laatupisteytyksessä, niin "laatutoimittaja" tulee valita, oli sen tarjouksen hinta vaikka kuinka korkea. (Vaikka se ei saisi juuri yhtään hintapistettä, niin laadusta saadut 50% takaisivat valinnan, koska muut eivät saaneet laatupisteitä).
"Maksaa mitä tahansa" on kova hinta, kun kyse on kuitenkin vain "ylimääräisestä" laadusta.
JOHTOPÄÄTÖKSET
Looginen johtopäätös on, että hankinnoissa laatu pitäisi erityisesti määrittää pakollisissa vaatimuksissa. Tämä tarkoittaa sen ymmärtämistä ja määrittämistä, mikä on "riittävän hyvä": mitä ovat sitä kuvaavat mittarit ja tavoitetasot. Ei varmasti monesti ole helppoa, mutta siihen nähdäkseni tulisi pyrkiä ja on siis erittäin keskeinen hankkijan tehtävä.

Jos näin toimittaisiin, tämä tarkoittaa myös kulttuurillista muutosta toimittajapuolella. Nykyään toimittajat "ruksivat" täyttävänsä pakolliset vaatimukset (koska muuten pullahtaisivat pois kilpailutuksesta). Jos pakollisissa vaatimuksissa aidosti edellytetään laatua, niin ruksiminen kyllä edellyttäisi toimittajilta aitoa pohtimista, mihin he oikeasti sitoutuvat.

Miten paljon laatua sitten valintakriteereihin? Mielestäni ylimääräiseen laatuun tulisi laittaa (veronmaksajien) rahoja vain hyvin perustellusti.

MUTTA...
Tämä kirjoitus on luonteeltaan "järkeilyä" ja voi olla idealistinen. Käytännön realiteetit voivat asettaa omat haasteensa. Varmaan yksi sellainen on, että jos kukaan tarjoajista pysty pakollisiin vaatimuksiin.

Ja voi tuossa järkeilyssäkin olla jokin pielessäkin. Palautetta otan mielelläni vastaan (mielellään nimi näkyviin!)

Koulutus "Käytettävyys tietojärjestelmien hankinnoissa" 12.3.2012

2012-01-11T10:14:00.002+02:00

Koulutuksen tiivistetty kuvaus:

Yksi suurimmista ja yleisimmistä tietojärjestelmien riskeistä on järjestelmien vaikeakäyttöisyys ja kaikkiaan epäonnistunut käyttäjäkokemus. Vaikeakäyttöisistä järjestelmistä kärsitään laajasti eri aloilla terveydenhuollosta VR:n verkkopalveluihin. Tämä on tilanne tänään, vaikka päättäjien keskuudessa tehtyjen tutkimusten mukaan helppokäyttöisyyttä kuitenkin pidetään yhtenä tärkeimpänä tietojärjestelmien laatukriteerinä.

Käytettävyys tietojärjestelmien hankinnoissa -koulutuksessa käydään läpi käytettävyyden varmistamiseen liittyviä haasteita, nykyisten käytäntöjen ongelmakohtia ja esitetään vaihtoehtoisia toimintamalleja, joilla käytettävyys aidosti saataisiin mukaan projekteihin. Uudet toimintamallit tarkoittavat aika merkittäviä muutoksia nykyisiin hankintakäytäntöihin. Päivän koulutuksen tarkoituksena ei ole antaa keittokirjamaista ratkaisua, vaan lähtökohdat ja valmiudet oman toiminnan kehittämiseen sekä oikeiden valintojen tekemiseen.

Koulutuksessa keskitytään erityisesti käytettävyyteen asiakaskohtaisten järjestelmien hankinnassa, mutta sivutaan myös valmisohjelmistojen hankintaa. Koulutus on tarkoitettu tietojärjestelmäprojekteissa oleville henkilöille niin hankkijapuolella kuin toimittajapuolellakin. Koulutuksen aluksi käydään läpi käytettävyyden keskeiset perusteet, jolloin koulutus soveltuu myös henkilöille, joille käytettävyys ei ole kovin tuttua.

Koulutuksen järjestää Tietotekniikan liitto. Ks. koulutuksen tarkempi ohjelma

Uusi kirja käytettävyydestä (käyttäjäkokemuksesta) julkishallinnon järjestelmissä

2012-01-10T14:08:00.002+02:00

Kohta ilmestyy kirja "Usability in Government Systems" (Morgan Kaufmann).

Kirjasta on alustavaa tietoa kirjan alustavilla sivuilla. Sivuilla ei vielä ole edes sisällysluetteloa, mutta kirjoittajat koostuvat alan kansainvälisistä asiantuntijoista.

Kirjoitin siihen yhden kappaleen amerikkalaisen kollegani Elizabeth Buien kanssa: "Getting UX into the contract". Tiivistelmä:

Poor usability persists in government systems mainly because government agencies fail to specify usability in a way that ensures the production of adequately usable systems, or are not prepared to ensure usability by themselves. This chapter looks at how governments initiate system development projects, prepare RFPs and proposes some approaches to solving the problem. It uses examples from Finland and the United States to illustrate the concepts it presents.

Kerron sitten tarkemmin, kun kirjasta sisällöstä ja julkaisuajankohdasta tulee tarkempaa tietoa.

"Yhdessä käyttäjien kanssa" -sudenkuoppa

2011-12-08T12:57:00.001+02:00

Huomasin Jaakko Talvitien mielenkiintoisen blogikirjoituksen: http://www.activityblog.fi/2011/12/liikaa-insinooreja/:

"... Entä jos ohjelmistotuotannossa otettaisiin käyttöön laitetuotannon tapa käyttää muotoilijoita? Insinöörit ja muut ohjelmistoammattilaiset keskittyisivät suunnittelemaan ja toteuttamaan tietojärjestelmän, jonka muotoilijat ja käytettävyyden spesialistit ovat hahmotelleet yhdessä käyttäjien kanssa. Tällöin tärkeää ei olisi pelkästään se, mitä ohjelmistolla voi tehdä, vaan myös se, miten sitä käytetään ja erityisesti se, miltä sen käyttäminen (kyllä vaan!) tuntuu."

Jaakon kirjoituksessa on asiaa. Mutta varmuuden vuoksi muutama täsmennys:

Suunnittelu ("hahmottelu") yhdessä käyttäjien kanssa on sudenkuoppa. Käyttäjät ovat kyllä olleet mukana perinteisestikin tietojärjestelmäprojekteissa - huonoin tuloksin. Suunnittelun pitää perustua käyttäjätietoon, mutta pointti on siinä, miten käyttäjätieto saadaan ja miten se otetaan mukaan suunnitteluun. Tässä on mielestäni monilla "käytettävyysasiantuntijoillakin" erheellisiä käsityksiä (käytettävyysasiantuntija lainausmerkeissä, koska sellaista muodollista pätevyyttä ei kenelläkään ole - ei myöskään minulla...)
Myöskin on erheellisiä käsityksiä, mistä käyttäjälähtöisyyden suunnittelun tulisi lähteä. Itse erityisesti korostan tietoarkkitehtuurin määritystä käyttäjälähtöisesti http://kaytettavyysnavigoija.blogspot.com/2011/05/kayttajalahtoinen-tietorakenne.html
Muotoilulla on selkeä roolinsa, mutta yleensä ei homma siitä kiikasta. Monesti on jopa haittaa siinä mielessä, että homma kuvitellaan ratkaistavan sillä, että laitetaan mainostoimisto asialle.
Mikä on oikea tapa ottaa käyttäjät mukaan? Siitä olen kirjoitellut tässä blogissa aiemmin ja käytettävyysnavigoija-blogissa, samoin kirjassani.
Käytettävyyden aikaansaaminen tietojärjestelmissä on lisäksi - ja erityisen paljon - hankinnallinen ongelma (mihin asiaan tämä blogi on erityisesti keskittynyt).
Yksi aiheeseen liittyvä artikkeli: http://hankikaytettavyytta.blogspot.com/2011/11/timon-vieraskyna-hesarissa-9112011.html
Käyttäminen "tuntuu" hyvältä kun järjestelmä tukee käyttäjän työtä: käyttäjä saa vaivatta aikaiseksi haluamiaan tuloksia.

Esko Aho valtion tietojärjestelmähankinnoista Hesarissa - ja vähän Timokin

2011-12-01T15:48:00.001+02:00

Osataan sitä Aasiassakin... samalla tavalla väärin kuin Suomessa

2011-11-23T21:49:00.001+02:00

Olen tutkinut tietojärjestelmien tarjouspyyntöjä Suomessa siitä näkökulmasta, että missä määrin käytettävyyttä vaaditaan tai se on valintakriteeri. (niinkuin blogin lukijat varmaan ovat huomanneet;)

Ja tuloksena siis se, että eipä näy tarjouspyyntöjä, jossa sitä aidosti vaadittaisiin, tai jossa se olisi aito valintakriteeri.

Vähän ollut joskus ollut epävarmuutta siitä, että millä tasolla muualla maailmassa mennään. Ja nyt sain viitteitä siitä, että eipä näytä muualla olevan sen kummempaa. Sain juuri amerikkalaiselta kolleegaltani (jonka kanssa olen kirjoitellut aiheesta) viestin, jossa hän on tutkaillut eräältä aasialaiselta julkiselta organisaatioilta tullutta tarjouspyyntöä. Ja ko. tarjouspyynnössä lukee mm:

The proposed system shall include an online help facility within the respective

modules. The online help facility shall be user friendly and intuitive.

Suomalaisissa tarjouspyynnöissä näkyy ihan samantyylisiä "vaatimuksia". Ks. esim. http://hankikaytettavyytta.blogspot.com/2011/08/jarjestelman-on-oltava-helppokayttoinen.html, http://hankikaytettavyytta.blogspot.com/2011/05/toivomuslistoilla-ei-aikaansaada.html,

Globaalia näyttää olevan ainakin kaksi asiaa:

Positiivisessa mielessä se, että hankkijat kantavat huolta käytettävyydestä; ei kai muuten tällaisia vaatimuksia esitettäisi
Negatiivisessa mutta mielenkiintoisessa mielessä se, että ihan eri paikoissa ollaan päädytty sellaisiin vääriin ratkaisuihin, jotka ovat melkeinpä täsmällisesti samanlaisia (tuskin aasialaiset ovat tuota suomalaisista tarjouspyynnöistä kopioineet...)

Tosi sudenkuoppa: "tarvitaan osaavampia käyttäjiä"

2011-11-17T07:16:00.001+02:00

Yhdessä seminaarissa erään ohjelmistotalon edustaja sanoi, että suunnitteluprojektissa tarvitaan "osaavampia käyttäjiä", jotta järjestelmistä tulisi helppokäyttöisempiä.

Tosi sudenkuoppa.

Miksi ei näin: Jos on käyttäjiä mukana projektissa eikä tuloksena saada käyttäjäystävällistä järjestelmää, niin vika ei ole käyttäjissä, vaan sitä tulee etsiä järjestelmän kehittäjistä.

Miten tulisi toimia: Lähtökohta tulisi olla, että käyttäjät ovat aina osaavia. Käyttäjien osaamiseen suunnitteluhankkeissa tulee riittää se, että he osaavat oman työnsä. Käyttäjiä tulee pitää tiedon lähteenä omasta työstään. Suunnittelijoiden rooli on jäsentää tämä tieto suunnitteluratkaisujen pohjaksi.

----------------
(Tämä on vanhasta, ei enää verkossa olevasta blogistani vuodelta 2010. Ja tuo seminaari oli siis 2010. Mutta asia on edelleen ajankohtainen)

Käytettävyysongelmat kannattavaa businesta järjestelmäkehityksessä?

2011-11-15T15:27:00.001+02:00

Käytettävyyspäivän 10.11.2011 KäytettävyysOSYn ja SIGCHI Finlandin seminaareissa toin esiin, että käytettävyys on kovastikin eri asia järjestelmäkehityksessä kuin tuotekehityksessä.

Mitä tällä tarkoitan?

Erityisesti sitä, että raha liikkuu ihan eri tavalla. Tuotekehitysyritys kärsii taloudellisesti käytettävyysongelmista, kun taas ohjelmistokehittäjäyritys saa lisää tilauksia käytettävyysongelmista.

1. Tuotekehitys

Kun tuotteita kehittävä yritys epäonnistuu käytettävyydesssä, se ennen pitkään näkyy siinä, että ei pärjää markkinoilla. Myynti vähenee, ja tuotot menevät kilpailijoille.

2. Järjestelmäkehitys (jossa hankkija ja kehittäjä ovat eri organisaatioita, esimerkiksi julkinen virasto ja ohjelmistoyritys)

Jos ohjelmistoyritys kehittää ratkaisuja, jotka ovat käytettävyydeltään ongelmallisia, niin tämän päivän hankintasysteemeillä hankkija joutuu tekemään lisätilauksen ohjelmistoyritykseltä ongelmien korjaamiseksi (jos haluaa ongelmat korjatuksi). Siis ohjelmistoyritys saa lisää tilauksia ja rahaa, kun sen itse tekemissä suunnitteluratkaisuissa on käytettävyysongelmia.

Korostan kuitenkin, että ohjelmistoyritykset varmaan eivät tee tietoisesti näin. Mutta nykyinen "käytännön käytäntö" periaatteessa tukee tällaista toimintaa.

Johtopäätös? No tietenkin se, että järjestelmäkehityksen ja erityisesti hankinnan käytäntöjä tulisi kehittää.

Kyse ei siis ole siitä, että tietojärjestelmät olisivat jotenkin hankalampia kehittää helppokäyttöisiksi. Tämä tuli esille hyvin Jouni Linkolan (Tieto) mielenkiintoisessa esityksessä KäytettävyysOSYn seminaarissa. Mutta tästä lisää myöhemmin.

PS. Tämä ei ole ainoa syy. Merkittävä syy on ainakin myös se, että käyttäjät otetaan usein mukaan projekteihin väärissä rooleissa. Tästä olen kirjoitellut tässä blogissa jo aiemmin, sekä myös kirjassani. Mutta ehkä tähänkin vielä palataan myöhemmin.

Timon vieraskynä Helsingin Sanomissa 9.11.2011

2011-11-11T15:53:00.001+02:00

Tarkempi teksti:
http://www.hs.fi/paakirjoitukset/Atk-hankinnoissa+vastuu+kuuluu+tilaajalle/a1305548959593

Käytettävyys tärkein kriteeri paitsi että ei ole kriteeri ensinkään

2011-11-09T07:16:00.001+02:00

Vasta ilmestyneen tutkimuksen (http://www.editori.fi/marraskuu-2011/tutkimukset-marraskuu-2011/tietojarjestelmat-ja-ict-palvelut-paattajatutkimus/) mukaan päättäjien mielestä tietojärjestelmän helppokäyttöisyys (käytettävyys) on ICT-hankintojen tärkein hankintakriteeri.

Taas Oulun yliopistossa 2010 tehty tutkimus (kerrottu aiemmin tässä blogissa http://hankikaytettavyytta.blogspot.com/2011/04/tutkimus-kaytettavyytta-ei-vaadita .html) samoin kuin oma jatkuva tietojärjestelmien julkisten tarjouspyyntöjen seuranta kertovat, että yhdessäkään tarjouspyynnössä helppokäyttöisyys ei ole aito hankintakriteeri.

Että tämmöistä.

Voisiko johtopäätös olla, että käytettävyyden aitoon vaatimiseen tulisi kiinnittää huomiota järjestelmien tarjouspyynnöissä? Se on menetelmällisesti käytettävyyden vaikeimpia lajeja (mutta mahdollista!) ja muuttaisi myös käytännön hankintakäytäntöjä aika radikaalisti niin hankkijoiden kuin toimittajienkin näkökulmasta. Jopa siinä määrin, että itse olen ruvennut vähän pessimistiseksi asian suhteen.

Mutta tällaiset tutkimustulokset kyllä antaisivat pohjaa, että jospa sittenkin...?

Käytettävyysseminaarin oikea linkki

2011-11-03T10:29:00.001+02:00

on sittenkin tämä: http://www.sytyke.org/toiminta

Maailman käytettävyyspäivän 10.11.2011 seminaari: "Käytettävyys tietojärjestelmien suunnittelussa - mikä tökkii, mitä ratkaisuja?"

2011-11-01T07:58:00.003+02:00

Nykyiset älypuhelimet, jotka on kehitetty miljoonille erilaisille käyttäjillä ovat radikaalisti helpompia käyttää kuin tietojärjestelmät, jodien käyttäjäkunta on yleensä suppea ja hyvin tunnistettu. Miten tämä on mahdollista? Tilannehan pitäisi olla päinvastoin - käytettävyyden suunnittelun keskeinen lähtökohta kun on "tunne käyttäjäsi".

World Usability Day -tapahtuma

Paikka: Haaga-Helia, Ratapihantie 13, Pasila, Helsinki. Luokka 2209

Aika: to 10.11.2011 klo 9:30 - 11:45 (- 12:00)

Tarkemmat tiedot ja ilmoittautuminen: (huom! Aiemmin tässä ollut linkki ei toiminut):

http://www.sytyke.org/k%C3%A4ytett%C3%A4vyysosyn-seminaari-10112011-k%C3%A4ytett%C3%A4vyys-tietoj%C3%A4rjestelmien-suunnittelussa-mik%C3%A4-t%C3%B6kkii-mit%C3%A4

Käytettävyyssuunnittelun perustandardi ilmestynyt suomeksi

2011-10-24T08:39:00.002+03:00

http://kaytettavyysnavigoija.blogspot.com/2011/10/kaytetttavyyssuunnittelun-perustandardi.html

Millaista on käytettävyysasiantuntijan työ Logicalla, Tiedolla ym?

2011-10-07T12:20:00.000+03:00

("ym." otsikossa tarkoittaa yleensäkin julkiselle taholle, esimerkiksi terveydenhuollolle, järjestelmiä kehittäviä ja toimittavia yrityksiä).

Joka tätä blogia on seurannut, tietää, että seuraan julkisen tahon tekemiä tietojärjestelmien tarjouspyyntöjä.

Havaintona siis se, että sellaisia tarjouspyyntöjä ei käytännössä ole, jossa käytettävyyttä aidosti vaadittaisiin tai jossa käytettävyys olisi aito kilpailutuskriteeri (mikä sinällään ei ole ihme, koska käytettävyyden vaatiminen on menetelmällisesti todella haastavaa).

Tästä seurauksena on tietenkin se, että toimittajien ei käytännössä tarvitse - eikä kannata - aidosti sitoutua toimittamaan hyvää käytettävyyttä/ helppokäyttöisiä järjestelmiä.

Tiedän, että järjestelmien toimittajilla (kuten Logicalla ja Tiedolla) on palveluksessaan käytettävyysasiantuntijoita. Aina joskus mietin heidän rooliaan projekteissa.

Ja tohdin tehdä tällaisen, toivottavasti ei liian provosoivan kysymyksen: Millaista on käytettävyysasiantuntijan työ projekteissa, jossa asiakas ei aidosti vaadi käytettävyyttä eikä projekti käytännössä ole aidosti sitoutunut toimittamaan käytettävyyttä? Vai ovatko käytettävyysasiantuntijat yleensäkään mukana näissä projekteissa?

Vai meneekö tässä ajatteluketjussani jokin pieleen?

Haluaisiko joku kertoa ajatuksiaan/ kokemuksiaan?

(Yleensä toivon, että kommentoitaisiin nimellä. Mutta ehkä tässä tapauksessa joku haluaa vastata anonyymisti)

Älä laita käyttäjää jäsentämään työtään!

2011-10-07T09:51:00.000+03:00

Lue Käytettävyysnavigoija-blogista:
http://kaytettavyysnavigoija.blogspot.com/2011/10/ala-laita-kayttajia-jasentamaan-tyotaan.html

Käytettävyysvaatimus tarjouspyynnössä -pähkinä

2011-10-03T13:39:00.001+03:00

Yksi tarjouspyyntö pisti silmään, jossa käytettävyys on huomioitu pakollisissa vaatimuksissa pariinkin kertaan:

1. "... tarvitaan selkeä jahelppokäyttöinen työkalu. Siirtyminen ... tasolta seuraavalle tulee ollahelppoa..."

Tukeeko toimittaja edellä kuvattua ominaisuutta?

Vastaus:___"

2. ".... (toiminnallisuuden) tulee olla helposti ymmärrettävässä ja käsiteltävässä muodossa jaraporttien ottaminen tulee olla helppoa..."

Tukeeko toimittaja edellä kuvattua toiminnallisuutta?

Vastaus:___"

Eli tarjouspyynnössä edellytetään, että toimittajan tulee sitoutua yllä olevien vaatimusten täyttämiseen. Eli toimittajan tulisi vastata yo. kysymyksiin "Kyllä" tai muuten tipahtaa kilpailusta pois.

Kysymys lukijoille: Mitä hyvää ja mitä ongelmia yllä olevissa käytettävyysvaatimuksissa?

JHS vaatimusmäärittelysuositus määrittelee käytettävyyden hyvin - melkein

2011-09-26T13:46:00.000+03:00

Käytettävyysvaatimukset ovat luonteeltaan ei-toiminnallisia vaatimuksia, jotka asettavat ehtoja toiminnallisten vaatimusten suunnittelulle

Jatkanpa taas JHS vaatimusmäärittelysuosituksen (http://www.jhs-suositukset.fi/web/guest/jhs/recommendations/173) tarkastelua käytettävyysvaatimusten määrittämisen näkökulmasta (jatkoa muutamalle aiemmalle kirjoitukselleni).
Suositus määrittelee ihan mukavasti käytettävyyden perusasioita, mutta sisältää muutaman lipsahduksenkin.

Suositus määrittelee käytettävyyden ISO 9241-11 mukaisesti: "mitta, miten hyvin määrätyt käyttäjät voivat käyttää tuotetta tietyssä käyttötilanteessa saavuttaakseen määritetyt tavoitteet tuloksellisesti, tehokkaasti ja tyytyväisinä". Ja tämähän on hyvä käytettävyyden määritelmä.

Käytettävyys on ei-toiminnallinen vaatimus. Tulkintani mukaan myös suositus sisällyttää käytettävyyden ei-toiminnalliseksi vaatimukseksi. Tosin asia on ilmaistu ei-toiminnallisten vaatimusten luettelossa jostain syystä vähän epätäsmällisesti (suosituksen kohta 11.4): "tietojärjestelmän opiskelun ja käytön helppous".

Ei-toiminnallista vaatimuksista - mihin siis käytettävyysvaatimukset kuuluvat - suositus toteaa: "Ei-toiminnalliset vaatimukset määrittelevät rajoitukset ja reunaehdot toiminnallisille vaatimuksille." Ja tämä lausuma pätee hyvin myös käytettävyysvaatimuksille. Lyhyesti ilmaistuna, käytettävyyden "rajoitukset ja reunaehdot" ovat sitä, että toiminnallisuudet tulee suunnitella siten, että ne aidosti tukevat käyttäjän työtä.

Mutta sitten suositus toteaa, että "Ei-toiminnalliset vaatimukset eivät liity suoraan palveluihin vaan kertovat, mitä ehtoja järjestelmän on täytettävä, jotta toiminnalliset vaatimukset voidaan toteuttaa."

Tämä teksti on kyllä vähän harhaanjohtavaa:

Käytettävyysvaatimukset kyllä oleellisesti liittyvät "palveluihin", jos palveluilla tarkoitetaan käyttäjille annettavaa palvelua. Kun käytettävyys on käyttäjän tehtävien tukemista, niin käytettävyysvaatimukset on pakosta määritettävä palvelutasolla.
Käytettävyysvaatimukset eivät ole toiminnallisten vaatimusten toteutusehto - kuten varmaan kaikki ovat nähneet, toiminnallisuutta toteutetaan vaikka kuinka ilman käytettävyyttä. Ehkä tuossa onkin tarkoitettu sanoa "Ei-toiminnalliset vaatimukset ... kertovat, millä ehdoilla toiminnalliset vaatimukset tulee suunnitella" (tms.)?

Näin määritetään todennettava käytettävyysvaatimus

2011-09-14T06:50:00.001+03:00

Lähestytään "todennettava käytettävyysvaatimus" -asiaa JHS-suosituksen käytettävyysvaatimusesimerkin kautta (olen kirjoittanut esimerkistä aiemmin:

Tarkastellaan nyt taulukon vaatimusten todennettavuutta. Eli onko vaatimukset määritetty sillä tavoin, että niiden saavuttaminen voidaan yksikäsitteisesti testata? Että ei tule erimielisyyksiä hankkijan ja toimittajan välillä siitä, että täyttyykö vaatimus vai ei.

Lyhyt vastaus on: ei. Vaatimus "Käyttäjän on voitava muuttaa salasanaa järjestelmää käyttäessään 30 sekunnin suoritusajassa" ei määrittele sitä, milloin vaatimus täyttyy. Vaatimus jättää avoimeksi:

miten vaatimuksen täyttyminen testataan

jos käytetään käytettävyystestiä, kuinka monella ja millaisella käyttäjällä testataan

onko ihan kaikkien käyttäjien suoriuduttava vaatimuksesta

Jotta vaatimus olisi todennettava, on määritettävä mittari, mittausinstrumentti ja tavoitetaso

Tässä mittari voisi olla esimerkiksi käyttäjätehtävän onnistumisaste, määriteltynä kuinka monta prosenttia testihenkilöistä suorittaa tehtävän oikein

Luonteva mittausinstrumentti on käytettävyystestaus. Tämä on sitten määritettävä tarkemmin: kuinka monella ja millaisilla testihenkilöllä, miten testausproseduuri tarkemmin toteutetaan, mikä on "oikea suoritus" jne.

Tavoitetaso olisi tässä tapauksessa onnistumisasteen prosenttiluku

Esimerkiksi voidaan määrittää, että

testataan 10 hengen testiryhmällä

testiryhmä valitaan satunnaisesti organisaation nykyisistä työntekijöistä

testi suoritetaan seuraavasti: (tarkempi määrittely....)

tavoitetaso on 100%, eli kaikki testin henkilöt suorittavat tehtävän oikein

-------------------------------

Tälläisella systematiikalla saadaan vaatimuksesta todennettava. Mutta asia ei ole kuitenkaan ihan näin yksinkertainen:

Entä jos testiporukkaan sattuu sellainen "tumpelo", joka ei onnistukaan tehtävässä? Onko testi reilu toimittajalle? Vaatimushan oli 100% onnistunutta suoritusta, jolloin yksikin epäonnistuminen tarkoittaa, että vaatimus ei täyty. Olisiko sittenkin ehkä 90% kohtuullisempi vaatimus?

Toisaalta 100% testikäyttäjänkään onnistuminen ei suinkaan tarkoita, että järjestelmän kaikki käyttäjät onnistuisivat tehtävässä. Käyttäjäotoksella saadaan ainoastaan tietty luottamus siihen, mikä osuus käyttäjistä vähintään suorittaa tehtävän oikein. Esimerkiksi 10 käyttäjää 10:stä onnistuu tarkoittaa sitä, että 95% luottamuksella vähintään 75% kaikista käyttäjistä onnistuu. Ks. http://www.measuringusability.com/comp_sample.php

Eli jos vaatimukset haluaa määrittää "kunnolla", asiaa tulee lähestyä lopulta tilastollisesti.

Ja sitten on vielä asia erikseen, että mikä on validi käytettävyysvaatimus. Eli mitä ovat validit mittarit ja mitä validit tavoitetasot? Tähän asiaa palaan myöhemmin. (tai olenhan asiaa sivunnut jo aikaisemmissakin kirjoituksissa)

Käytettävyys pakollisina vaatimuksina eikä pisteytettävinä valintakriteereinä!

2011-09-09T15:28:00.001+03:00

Tuossa aiemmin annoin pientä pohdittavaa JHS-suosituksesta: http://hankikaytettavyytta.blogspot.com/2011/08/jhs-suosituksen-kaytettavyysvaatimusesi.html (eipä ole tullut kommentteja, vielä ehtii...)

Kyseessä siis JHS-suosituksen esimerkki:

Ja yksi muu näkökulma tuosta esimerkistä:

Esimerkistä on tulkittavissa, että vaatimukset ovat on pakollisia minimitason vaatimuksia (vaikka "tärkeys = 2" onkin hämäävä). Eli toimittajan on sitouduttava siihen, että järjestelmä täyttää nuo vaatimukset. Ja tämä on hyvä asia: käytettävyysvaatimukset tulisi määrittää pakollisiksi, ei-pisteytettäviksi vaatimuksiksi tarjouspyynnöissä (jos käytettävyyttä nyt toimittajlta yritetään edellyttää).

Tämä kahdesta perusteesta:

Jos käytettävyys on pisteytettävä vaatimus (niinkuin hyvin usein on), niin silloin voi tulla valituksi muiden ominaisuuksien perusteella toimittaja, joka ei saa "hyviä" pisteitä käytettävyydestä. Tällöin käytettävyys siis jää jo sitä kautta lapsipuolen asemaan
Ja tämä ehkä vielä oleellisempi perustelu: on loogista, että käytettävyydelle on määritetty järkevä minimitaso jo liiketoimintasyistä. Siis selkeä määritelty tavoite, milloin käytettävyys on hyväksyttävällä tasolla. Eli milloin järjestelmä on riittävän hyvä käyttäjien kannalta.

Tuon käytettävyyden minimitason määrittäminen lähtee halutusta käytettävyyden vaikuttavuuden määrittämisestä (tässä englanti ehkä ymmärrettävämpää suomalaisellekin: desired usability impact), ks. http://kaytettavyysnavigoija.blogspot.com/2011/06/haluttu-kaytettavyysvaikuttavuus.

Tämä on asia - siis käytettävyyden vaikuttavuuden määritys - jota alan kirjallisuus ei oikein ota esiin. Mutta näin se loogisesti tulee mennä.

"Asiakas hyväksyy" EI ole yhtäkuin käytettävyys

2011-09-06T15:53:00.001+03:00

Aiempaa kirjoitustani käytettävyyden validoinnista kommentoitiin ketterän kehityksen käyttäjälähtöisyydellä (http://hankikaytettavyytta.blogspot.com/2011/09/kaytettavyyden-validointi-edellyttaa.html?showComment=1315308433056#c26718616511358904).

Käyttäjälähtöisyys on tietenkin periaatteessa hyvä lähtökohta. Mutta käyttäjien mukanaolo ei sinällään takaa yhtään mitään käytettävyydestä (keskeinen kysymys on, miten käyttäjät otetaan mukaan).

Jo usampi vuosi sitten olin tekemässä studya, jossa käytiin läpi VTT:n tekemä ketterän kehityksen esimerkkiprojekti käytettävyysnäkökulmasta (raportoitu: http://www.informatik.uni-trier.de/~ley/db/conf/profes/profes2004.html#JokelaA04). Tuoteomistaja - asiakas ja myöskin käyttäjä - oli mukana projektissa aktiivisessa roolissa. Kuitenkin projektin käytettyvyyden kypsyystasoksi saatiin karkeasti "0" (asteikolla 0...4). Kuten em. artikkelin otsikossa sanotaan, "Close Co-operation with the Customer Does Not Equal to Good Usability".

- Otetaan yksi kohta edellä viitatusta kommentista: "Scrum-kehityksessä käytettävyyden huomioiminen on periaatteessa helppoa, koska työn määrittelyn välineenä olevien käyttäjätarinoiden (User Stories) muotoilu on käyttäjälähtöistä. Tällöin kirjoituksen lainauksessa mainittu toimintatapa, jossa prototyypillä ("realistisella sovelluksen simulaatiolla"), on mielekäs kun siinä hyväksytetään alkuperäisen määrittelyn toiminnallisuudet asiakkaalla tai tuoteomistajalla (Product Owner)... Milloin on riittävän hyvä" on silloin kun tietyn käyttäjätarina voidaan hyväksyä tehdyksi (Definition of Done)."

Tässä siis tulkintani mukaan sanotaan, että hyvän käytettävyyden kriteeri on se, että asiakas hyväksyy toteutetun käyttäjätarinan.

Ja minun kommenttini on, että asiakkaan hyväksynnällä ei tarvitse olla mitään tekemistä käytettävyyden kanssa. Käytettävyyden kriteeri ei ole se, että "asiakas hyväksyy" vaan se, että "miten hyvin määrätyt käyttäjät voivat käyttää tuotetta määrätyssä käyttötilanteessa saavuttaakseen määritetyt tavoitteet tuloksellisesti, tehokkaasti ja miellyttävästi" (ISO 9241-11 määritelmä; ks. myös http://kaytettavyysnavigoija.blogspot.com/2011/08/mika-olikaan-kaytettavyyden-maaritelma.html).

Käytettävyyden validointi edellyttää kriteereiden määrittämistä

2011-09-02T08:12:00.000+03:00

Eräällä LinkedInin keskustelupalstalla on herännyt keskustelua käytettävyyden varmistamisesta.

Siellä on mielenkiitoisia puheenvuoroja. Tässä kommentti yhteen sellaiseen (tarkoitukseni oli käydä blogissa seuraavaksi läpi JHS-suosituksia käytettävyyden kannalta, mutta lykätään sitä analyysia myöhemmäksi).

Petteri kirjoittaa: "... kuukausi UX parannusten kehittämiseen ketterässä kehityksessä on toooodella pitkä aika. Käytämme Rapid Design & Visualization (RDV) menetelmäämme yhdistettynä esim. Scrum-kehitykseen. Tällöin voimme kahden viikon Scrum -syklin aikana jo tehdä vähintään pari iteraatiota realistisella sovelluksen simulaatiolla ja kerätä siihen kommentit tai tehdä käytettävyystestit. Näin kaikki mitä on backlogissa on jo vähintään kertaalleen validoitu."

En tiedä tarkemmin, miten tuo prosessi alkupäässä menee. Kuitenkaan, jos ei ole alussa määritetty aitoja (valideja ja todennettavia) käytettävyysvaatimuksia, ei voida puhua validoinnista. Käyttäjäpalautteen kerääminen ja käytettävyystestaus ovat hyviä asioita, ja niillä käytettävyys todennäköisesti paranee. Mutta se jää auki, tuleeko riittävän hyvä. Validointiin tarvitaan kriteerit "milloin on riittävän hyvä".

Ihan niinkuin Pilvi kommentoi Petterin kirjoitukseen: "Iteratiivisen kehitystyön ja käyttäjätestausten vaatiminen ei varmaankaan riitä,mvaan edelleen on määriteltävä varhaisessa vaiheessa käytettävyystavoitteet ja pyrittävä mitattavuuteen?"

JHS-suosituksen käytettävyysvaatimusesimerkki: pientä pohdittavaa...

2011-08-31T12:08:00.001+03:00

JHS-suositus "173 ICTpalvelujen kehittäminen: Vaatimusmäärittely" antaa suosituksia, nimensä mukaisesti, tietojärjestelmän vaatimusmäärittelylle.

Suositus on yleinen, eikä se erityisesti keskity yksittäisiin laatuominaisuuksiin kuten käytettävyys. On kuitenkin mielenkiintoista tarkastella suosituksen sisältöä käytettävyyden suhteen, koska oletan, että suositusta käytetään referenssinä myös käytettävyyteen liittyvien vaatimusten määrittämisessä.

Otan tässä esiin suosituksessa olevan yhden esimerkin. Kohdan "11.1 Vaatimusluettelo ja tunnistetiedot" esimerkissä, s. 21, on (sattumoisin?) kaksi käytettävyysvaatimusta:

(vähän epäselvä kuva; blogiin ei kuitenkaan mahtunut siististi tarkempaa)

Esimerkki on siis tarkoitettu yleiseksi vaatimusluetteloa kuvaavaksi, ei mitenkään erityisesti käytettävyysvaatimusesimerkeiksi. Mutta kun kuitenkin ovat suosituksen esimerkkejä, niin tarkastellaan sitä tarkemmin tarkemmin. Aluksi yleisemmin, sitten validiuden ja todennettavuuden kannalta (ks. esim. http://hankikaytettavyytta.blogspot.com/2011/08/miksi-kaytettavyys-epaonnistuu.html).

1. Mitä käytettävyyden attribuuttia (http://kaytettavyysnavigoija.blogspot.com/2011/08/mika-olikaan-kaytettavyyden-maaritelma.html) esimerkin vaatimukset edustavat?

Erityisesti, onko kyseessä tuloksellisuus vai tehokkuus?

No, tämä on vähän teoreettinen kysymys; jätänpä sen lukijan pohdittavaksi/ kommentoitavaksi.

2. Ovatko vaatimukset valideja, sisällöllisesti oikeita?

Eli esimerkiksi jos käyttäjä voi muuttaa salasanaansa 30 sekunnin suoritusajassa, niin tarkoittaako se hyvää käytettävyyttä?

Tämäkin lukijan pohdittavaksi.

3. Ovatko vaatimukset todennettavia? Eli voidaanko niiden saavuttaminen yksikäsitteisesti todentaa?

----------------------
Ajattelin vastata itse ylläoleviin kysymyksiin, mutta jätänpä viimeisimmänkin kysymyksen aluksi lukijan pohdittavaksi ja kommentoitaviksi.

Voiko softan tekeminen olla näin vaikeaa?

2011-08-24T07:46:00.000+03:00

Kahden tilatiedon sitominen toisiinsa oli ohjelmistotoimittajalle ylivoimaisen vaikeaa

Kokemus projektista, jossa kilpailutettu toimittaja kehittää järjestelmää eräälle virastolle. Kyseessä järjestelmä, jossa virkailijat käsittelevät yhdenlaisia lupahakemuksia:

Käsittelyn aikana virkailijoiden tulee syöttää aika paljonkin erilaista tietoa järjestelmään: tietoa hakijasta, luvan kohteista, jne.
Sitten kun kaikki tiedot on syötetty, niin hakemus voidaan käsitellä; ja jos kaikki on ok, luvan tilaksi voidaan antaa myönnetty.

Hakemukseen liittyvä tietojen syöttö voi olla isokin urakka, eikä tapahdu välttämättä yhdellä virkailijan työrupeamalla (esimerkiksi kaikki tarvittava tieto ole heti saatavilla). Sen järjestelmästä tulisi näkyä se, että mitkä tiedot ovat valmiina ja miltä osin tietojen syöttö on kesken. Siis tilatiedot kuvaamaan tietojen syötön tilaa.

Ja nyt se varsinainen juttu: Järjestelmän toimittajalle oli liian iso juttu tehdä kohtuu hintaan/ ajassa sellaista toiminnallisuutta, jossa luvan hyväksyminen edellyttää, että tarvittavat tiedot on syötetty (tietojen syötön tilatiedot = valmis).

Lopputulos on sitten sellainen, että virkailija voi merkitä hyväksytyksi keskeneräiset hakemukset (hyväksymispainike on aktiivinen koko ajan). Ja voi sanoa, että lopputulos on käyttäjän kannata tosi hämäävä.

Ja se kysymys ohjelmistoasiantuntijoille: Miten kahden tilatiedon sitominen toisiinsa voi olla näin vaikeaa? Oman (tosin tosi vanhan) ohjelmointikokemuksen perustella olettaisin, että kyseessä olisi yksinkertainen perusjuttu.

"Järjestelmän on oltava helppokäyttöinen" - vaatimus, jolla ei merkitystä

2011-08-19T09:43:00.005+03:00

Jokainen järjestelmä täyttää vaatimuksen "järjestelmän on oltava helppokäyttöinen"

Erään asiakaskohtaisen järjestelmän tarjouspyynnön vaatimustaulukon yhdeksi pakolliseksi vaatimukseksi oli määritelty:

Järjestelmän on oltava helppokäyttöinen.

Tämä onkin yksi tyypillinen esimerkki, kun määritellään "käytettävyysvaatimuksia" tarjouspyyntöihin.

Mitä tällainen vaatimus oikeastaan tarkoittaa? Kun puhutaan "vaatimuksista vaatimukselle", niin vaatimuksen tulisi olla

todennettava (verifioitava): vaatimuksen täyttyminen voidaan tarkistaa niin, että ei tule erimielisyyksiä siitä, että toteutuuko vaatimus vai ei
validi: vaatimus on sisällöltään oikeita (= sen täyttyminen tarkoittaa, että kyseinen järjestelmä on "oikeasti" käytettävä)

Vaatimus Järjestelmän on oltava helppokäyttöinen ei ole todennettava, koska ei ole mitään yksiselitteistä ja yleisesti hyväksyttyä kriteeriä sille, milloin järjestelmä on ”helppokäyttöinen”. Vaatimus on aivan liian yleinen ja epämääräinen.

Tietääkseni tällaisessa tapauksessa toimittaja voi yksinkertaisesti ja yksipuolisesti todeta, että "järjestelmä on helppokäyttöinen". Piste. (vai tietääkö joku paremmin?)

Sitä kautta kaikki toimittajat voivat sitoutua tämän pakollisen vaatimuksen täyttämiseen ilman, että se merkitsee mitään järjestelmän aidon helppokäyttöisyyden näkökulmasta.

Vaatimus on tavallaan tietenkin validi (jos nyt halutaan helppokäyttöistä järjestelmää). Mutta kun vaatimus on niin epämääräinen (ei-todennettava), sen validiuden tarkastelu ei ole mielekästä.

Yhteenveto: vaatimuksella "järjestelmän on oltava helppokäyttöinen" ei ole käytännön merkitystä tarjouspyynnössä.

Miksi käytettävyys niin monesti epäonnistuu tietojärjestelmien hankinnoissa?

2011-08-12T12:01:00.001+03:00

Julkisen hallinnon tietojärjestelmien käytettävyysongelmat ovat tunnettu ongelma: henkilökunnan - ja monissa sovelluksissa myös asiakkaiden - aika menee tietojärjestelmien kanssa tuskaillessa. Tunnettu asia esimerkiksi terveydenhuollossa: http://www.laakariliitto.fi/files/ArviotkriittisiaVanska.pdf

Oma johtopäätökseni on, että juurisyytä tulee etsiä järjestelmien kilpailutus- ja hankintaprosessista. Yhtenä taustana on vaikka Oulun yliopistossa tehty tutkimus siitä, että käytettävyyttä ei aidosti vaadita tarjouspyynnöissä:
http://www.yourhost.is/images/stories/NordiCHI2010/accepted/281.html

Moni moittii kilpailutuslainsäädäntöä. Kuitenkin mielestäni se on annettu konteksti, joka tulee hyväksyä lähtökohtana. Se sitten tekee käytettävyysasioita haastavammiksi, mutta tähän haasteeseen olisi etsittävä ratkaisuja.

Tietojärjestelmän hankinnan käytettävyystoimenpiteet ovat erilaisia riippuen siitä, onko hankittava järjestelmä

asiakaskohtaisesti kehitettävä: hankitaan kehitystyötä
asiakaskohtaisesti sovitettava: perusrunko olemassa, johon tehdään asiakaskohtaisia muutoksia
valmisohjelmisto: esimerkiksi perustoimisto-ohjelmistot

Ensin mainitussa tapauksessa (1) järjestelmän käytettävyyttä ei voi hankintatilanteessa arvioida, koska järjestelmää ei ole olemassa. Käytettävyys pitää siis varmistaa muilla keinoin. Viime mainitussa tilanteessa (3) käytettävyyden arviointi nimenomaan tulisi suorittaa hankintatilanteessa. Ja keskimmäinen tapaus (2) menee tähän väliin.

Seuraavissa postauksissa käyn esimerkkien kautta läpi, miten nykyisissä tarjouspyynnöissä käytettävyyttä yritetään (jos yritetään) varmistaa, mikä niissä menee pieleen, ja miten asiaa voisi kehittää.

En ollutkaan poliisi

2011-06-23T07:56:00.003+03:00

Käytettävyysarvioinnin ei välttämättä tarvitse olla negatiiviseksi koettua "arvostelua". Ison organisaation verkkosivuista vastaavat henkilöt pitivät ulkopuolisen arviojan kanssa käymiään keskusteluja pelkästään positiivisina ja tarpeellisina.

Sanotaan, että suunnittelijat kokevat käytettävyysarvioinnit usein "poliisityönä". Eli arvioija tulee ja arvioi toisen suunnitteluratkaisuja, ja etsii niistä ongelmia (tosin arvioijan kuuluisi toki myös kertoa vahvuuksista).

Mutta eihän näin tietenkään tarvitse olla. Seuraava tapaus edustaa täysin päinvastaista kokemusta - oletan, että vastaavia kokemuksia on muillakin?

Arvioin ison julkisen organisaation kehitteillä olevat laajat verkkosivut. Kyseisten verkkosivujen eri alasivustojen suunnittelusta ja sisällöstä vastaavat kyseisen organisaation eri osastot. Kukin osasto oli siis tehnyt omalta osaltaan suunnitelmat alasivujen rakenteesta ja sisällöstä.

Kävin siis sivujen suunnitteluratkaisut läpi käytettävyysnäkökulmasta. Kommunikoin näkemykseni keskustelemalla puhelimitse kunkin alasivuston vastaavan kanssa. Ja tulos oli se, että jos etukäteen pelkäsin, että minut koettaisiin poliisina, niin tuo pelko oli täysin turha. Päinvastoin, poikkeuksetta kaikki keskustelut olivat erittäin rakentavia; verkkovastaavat olivat aidosti kiinnostuneita keskustelemaan sivuista, saamaan palautetta ja ottamaan vastaan kehitysehdotuksia. Näin koin itse, ja samaa raportoivat keskustelukumppanini työni tilaajalle (verkkosivujen kokonaisvastaava).

Eli oli erittäin mukava kokemus. Ja itse asiassa asiakkaan mielestä työni tärkein tuotos olikin nuo keskustelut (toki myös raportoin tulokset).

Sitten se mielenkiintoinen kysymys: mistä tämä positiivinen kokemus johtui? Itse tietenkin rohkenen ajatella, että pystyin antamaan ammattimaista palautetta sekä konkreettisia ja uskottavia kehitysehdotuksia. Mutta toisaalta tulkitsen, että nuo verkkovastaavat olivat olleet varsin yksinäisiä sivujen suunnittelussa. Vähän vaikutti, että muut organisaation ihmiset ovat niin kiireisiä muissa tehtävissään, että eivät kunnolla ehtineet perehtyä sivuihin ja antaa niihin palautetta. Ja kun minä sitten analysoin sivut syvällisemmin, niin tämä perehtyminen ja palaute koettiin positiivisena.

Jos en ollut poliisi, niin mikä sitten olin? Analogiana tulee mieleen urheiluvalmentaja, joka ulkopuolisin (ja ammattimaisin) silmin analysoi suoritusta ja neuvoo menemään eteenpäin. Ehkä jotain tällaista?

Käytettävyysjuttuja muissa blogeissa

2011-06-21T18:06:00.004+03:00

Tämän blogin päivittämisessä on ollut jonkin verran taukoa. Sen sijaan olen kirjoitellut yleisen tason käytettävyysasioista Käytettävyysnavigoija-blogiin:

nimikkeiden pituuksista:
http://kaytettavyysnavigoija.blogspot.com/2011/05/suosi-pitkia-nimikkeita.html

käyttäjälähtöisestä tietorakennesuunnittusta
http://kaytettavyysnavigoija.blogspot.com/2011/05/kayttajalahtoinen-tietorakenne.html

Nokian käyttöliittymäkohtalon taustoista
http://kaytettavyysnavigoija.blogspot.com/2011/06/nokian-kayttoliittymakohtalon-taustat.html

mitä on käytettävyysvaikuttavuus
http://kaytettavyysnavigoija.blogspot.com/2011/06/haluttu-kaytettavyysvaikuttavuus.html

mitä ovat käytettävyysvaatimukset
http://kaytettavyysnavigoija.blogspot.com/2011/06/mita-ovat-kaytettavyysvaatimukset.html

Käytettävyysasiantuntijan pisteytys

2011-05-18T17:41:00.003+03:00

Eräässä tarjouspyynnössä pisteytetään käytettävyysasiantuntijan ominaisuuksia alla olevan mukaan:

Tässä kriteereinä ovat siis koulutustausta, projektikokemus ja toimialatuntemus. Tällaiset kriteerit ovat helppo pisteyttää (kuinka monessa projektissa ollut mukana) - eli ne on todennettavia.

Mutta missä määrin tällainen pisteytys on validi; toisin sanoen miten nämä kriteerit oikeasti mittaavat käytettävyysasiantuntijan osaamista?

Se, että on ylempi korkeakoulututkinto, ei tarkoita, että olisi käytettävyysosaamista. Toki korkeampi koulutustaso luultavasti tukee analyyttistä jäsennyskykyä, mikä on ensiarvoisen tärkeää käytettävyystyössä
Työkokemus (tyyliin kuinka monessa projektissa toiminut käytettävyysasiantuntijana/ ollut mukana): Luonnollisesti antaa kuvan siitä, miten paljon on asian kanssa ollut tekemisissä, ja sitä kautta relevantti näkökulma. Mutta ongelma on, että ei kerro mitään tekemisen laadusta. Voi olla, että ongelmalliset tottumukset ovat vain kumuloituneet.
Toimialatuntemus: Tämä tietenkin antaa valmiuksia ymmärtämään toimialaa. Mutta toimialan oppiminen (mitä se tarkoittaa käyttäjien näkökulmasta) ei itse asiassa ole välttämättä iso ponnistus. Oma kokemukseni on, että ulkopuolelta uuteen toimialaan tulleena voi joskus tosi nopeastikin auttaa käyttäjiä jäsentämään heidän omaa työtään.

Käytettävyysasiantuntijan osaamisen arviointi validisti ei tosiaankaan ole yksinkertaista:

Yksi syy on se, että alalla ei ole mitään yleisesti sovittuja osaamis- tai pätevyysvaatimuksia. Eri opinahjojen koulutukset eivät ole yhteismitallisia. Jopa samaa aihealueen kurssit voivat opettaa asioita eri tavalla. (Itsekin olen joutunut opettamaan käytettävyystestauksen ihan perusasioita periaatteessa alan koulutuksen saaneille henkilöille).
Toinen syy on se, että käytettävyystyö on hirveän pitkälle älytyötä. Se ei ole mekaanista, vaan perustuloksetkin vaativat analyyttista otetta ja pohdintaa. Sen vuoksi kokemuskaan ei ole välttämättä hyvä indikaattori. (ks. Ralf Molichin tutkimukset: http://kaytettavyysnavigoija.blogspot.com/2011/04/mika-mahtaa-olla-kaytettavyystestien.html)

Ehdotus: Itselläni tulee ratkaisuksi mieleen aito koetilaisuus, jossa osaamista testataan jopa tenttimäisesti ja jäsennyskykyä analyyttisillä tehtävillä tai suunnittelutehtävillä. (toki kokemus ym. voivat olla mukana osakriteereinä).

Tällaisia en ole missään nähnyt. Eikä itsellänikään ole tällaisesta kokemusta hankintakontekstissa, eikä sitä kautta empiriaa idean toimivuudesta. Voi onko tällainen edes periaattessakaan (esim. lain puitteissa) mahdollista?

Olisiko joitakin ajatuksia tähän liittyen?

Toivomuslistoilla ei aikaansaada käytettävyyttä

2011-05-18T09:19:00.001+03:00

Eräässä terveydenhuollon tietojärjestelmän tarjouspyynnössä kannettiin selvästi huolta käytettävyydestä monessa kohden vaatimusmäärittelyä:

"Tunnistusmenettelyt tulee kehittää yksinkertaiseksi"
"Käyttöliittymässä tulee olla helppokäyttöiset linkit"
"Järjestelmässä käytettävien komentojen, termien, järjestelmähuomautuksien jne. tulee olla hyvää ja ymmärrettävää terveydenhuollon kieltä tai arkikieltä."
"Usein toistuvat samankaltaiset toiminnot, kuten potilaan valinta, toimintayksikön valinta, tulostus jne. tulee tapahtua kaikissa järjestelmän osissa yhdennäköisellä käyttöliittymällä."
"Tietojen, joita esitetään monilla eri näkymillä, sijainti ja järjestys tulee olla eri näkymissä samankaltainen."
jne.

Tämän tyyppiset "vaatimukset" eivät kuitenkaan käytännössä takaa mitään järjestelmän helppokäyttöisyydestä. Kyse on lähinnä toivomuslistoista.

Aluksikin vaatimuksissa on todennettavuusongelma. Esimerkiksi miten todentaa objektiivisesti, että vaatimus "käyttöliittymässä tulee olla helppokäyttöiset linkit" täyttyy tai ei täyty?

Toiseksi, käytännössä kuitenkin toimittaja hyväksyttää suunnitteluratkaisunsa asiakkaalla. Toisin sanoen asiakas lopulta teke päätöksen, että onko jokin suunnitteluratkaisu helppokäyttöinen vai ei. Eli vaatimukset eivät sitäkään kautta kohdistu toimittajaan.

Summa summarum: toivomuslistoilla ei aikaansaada käytettävyyttä

Vertaileva käytettävyystestaus demoilla ei toimi

2011-05-11T12:01:00.003+03:00

Käytettävyystestaus on periaatteessa toimiva ratkaisu järjestelmien käytettävyyden vertailussa. Tällaisia näkee joskus myös tarjouspyynnöissä valintakriteerinä. Esimerkiksi eräässä tarjouspyynnössä käytettävyystestauksen tuloksen painoarvo oli 50% valintaperusteesta:

"Tarjoajan toimitettava laitteisto ja demo järjestelmästä. Testauksessa analysoidaan tehtävän onnistumista, nopeutta, virhetoimintojen määrää... Mikäli käytettävyystestauksessa 30% käyttäjistä epäonnistuu, kyseinen tarjous hylätään".

Kuitenkaan demoilla tehtävä käytettävyystestaus ei anna välttämättä ollenkaan luotettavia ja valideja tuloksia. Syy on yksinkertainen: käytettävyystestaus on menetelmänä herkkä pienillekin suunnitteluongelmille. Testauksen tulokset voivat olla huonot esimerkiksi jonkin epäselvän termin vuoksi, joka olisi helppo muuttaa lopulliseen järjestelmään. Eli hylätyksi voi tulla järjestelmä, joka olisikin pienin muutoksin toimivin.

Käytettävyystestaus voi toimia validina vertailuperusteena valmisohjelmistojen hankinnassa. Mutta jos kyseessä on joko asiakaskohtaisesti räätälöitävä tai kokonaan asiakaskohtainen järjestelmä, käytettävyyden varmistamista tulee lähestyä muuta kautta.

Tähän ei ole välttämättä valmiita yleispäteviä ratkaisuja, vaan valintakriteerit tulee kehittää tapauskohtaisesti. Lähtökohtana tulisi periaatteessa olla päätös siitä, että jätetäänkö käytettävyys hankkijan vai toimittajan vastuulle. Vaikka jälkimmäinen on ehkä houkuttelevampi vaihtoehto, käytännössä luultavasti tulee kuitenkin lähteä siitä, että käytettävyyden varmistus jää viime kädessä hankkijan vastuulle. Käytettävyyden "vastuullistaminen" toimittajalta on mahdollista mutta metodologisesti vaativaa. Lisäksi tämän päivän toimittajamaailmassa tuskin ollaan sellaiseen vastuuseen vielä kypsiä.

Esimerkki käytettävyysvaatimuksesta, joka ei toimi

2011-04-29T16:46:00.009+03:00

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ä).

Käyttäjälähtöisyyden vaatiminen ei takaa käytettävyyttä

2011-04-29T07:05:00.008+03:00

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).

Prosessivaatimukset voisivat toimia, jos käytettävyystyö olisi mekaanista "tuotantotyötä". Mutta kun käytettävyystyö ei ole tällaista. Käytettävyystyö on "älytyötä", ja sen tulosten laatu riippuu tismalleen siitä, kuka sattuu tekemään noita prosesseja. Tutkimusten mukaan edes tunnettujen toimistojen tulokset ole välttämättä kummoisia: http://kaytettavyysnavigoija.blogspot.com/2011/04/kaytettavyyden-varmistus-ei-ole.html

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.

Käytettävyyttä ei vaadita kilpailutuksissa

2011-04-20T15:49:00.005+03:00

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ä. 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.

Muutoshallinta: käytettävyysongelmien vastuun vierityksen kulminaatiopiste

2011-04-19T08:32:00.001+03:00

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.

Se dramaattinen ero: käytettävyys hankinnoissa vs. tuotekehityksessä

2011-04-19T07:08:00.000+03:00

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.

Onko tämä dialogi? Tyypillinen esimerkki julkisen järjestelmän käytettävyysongelmasta

2011-04-18T10:35:00.003+03:00

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)

Käytettävyyden varmistus ei ole rutiinia

2011-04-17T19:47:00.001+03:00

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.