Matkakortinlukijan uusi versio: onko käytettävyysongelmat ratkaistu?

Vuosien 2016 - 2017 vaiheessa julkaisin moniosaisen analyysin silloin uudesta pääkaupunkiseudun paikallisliikenteen matkakortinlukijasta. Raportoin ongelmista niin lukijan käytettävyydessä kuin hankintatavassa.

Keväällä 2019 matkakortinlukijasta tuli uusi versio uusien matkustusvyöhykkeiden myötä. Paraniko käytettävyysongelmat uuden version myötä? Katso video alta (pituus: 3 min 32 sek).

MIllainen on UX -strategia?

Vaikka UX -strategiaa pidetään tärkeänä, konkreettiset esimerkit puuttuvat. 

Jotta saataisiin konkreettisia esimerkkejä, UXPA Boston järjesti "UX Strategy" -kilpailun osana 2019 UXPA Boston -konferenssia. Tanskalaisen UX-konsultin Rolf Molichin toimisto DialogDesign sponsoroi 3000 dollarin palkinnon jaettavaksi parhaille ehdotuksille. 

Kilpailussa jaettiin viisi palkintoa. Parhaan (1000 dollaria) sai Ann Thompsonin ehdotus. Neljä ehdotusta palkittiin "toisella" sijalla (500 dollaria) ja itse pääsin tähän joukkoon. 

Oma ehdotukseni arvioitiin seuraavasti: "It challenges assumptions about how we typically strategize. It differs from the other submissions in a thought-provoking way". En pidä arviotani yllättävänä - sen verran usein olen huomannut olevani "toisinajattelija" omalla alallani. 

Tietoa kilpailusta ja palkittujen UX-strategiaehdotukset löytyvät täältä. 

Millainen on onnistunut julkinen hankinta? Perusasiat

Julkisen hankinnan tavoite on hieno: asettaa tarjoajat samalla viivalle. Julkisen hankinnan osaamisen tärkein kriteeri on se, miten määrittää riittävä laatu tarjouspyyntöön. Tämä usein ymmärretään väärin ja tässä usein epäonnistutaan. 


Julkisen hankinnan ongelmat ovat nousseet viimeksi esiin, kun tuli ilmi yksityisten toimijoiden laiminlyönnit vanhusten hoidossa. Ja monet ovat moittineet julkista hankintaa, ja esittäneet erilaisia "parempia" tapoja, miten hankinnat pitäisi hoitaa.

Valitettavasti monilla kommentaattoreilla ei näytä olevan edes perusymmärrystä julkisen hankinnan perussäännöistä.

Seuraavassa yritän vetää yhteen julkisen hankinnan oleellisimmat piirteet. Tarkoitukseni on, että asiaan perehtymätönkin lukija saisi peruskäsityksen siitä, mistä julkisissa hankinnoissa on kyse.

Myös aiemmin olen kirjoitellut ja tehnyt videoita asiasta, esim.

• "Miksi julkinen taho hankkii hankalakäyttöisiä tie...
• Miten hankkia helppokäyttöisiä tietojärjestelmiä? ...
• Matkakortinlukija. Osa 1: Massiivia käytettävyyste... (moniosainen analyysi pääkaupunkiseudun matkakortinlukijan hankinnasta ja käytettävyysongelmista)

Julkisten hankintojen tavoite on hieno

Julkisten hankintojen käytännöillä on hieno tavoite: varmistaa se, että julkinen taho on puolueeton, että kaikki tarjoajat ovat samalla viivalla.

Siis että vältettäisiin tuttujen ja tiettyjen yritysten suosimista. Ja että tehtäisiin mahdolliseksi, että myös uusilla yrityksillä on mahdollisuus päästä tasapuolisesti mukaan julkisen tahon toimittajaksi.

Julkisia hankintoja ja sen käytäntöjä ei siis pidä itsessään arvostella. Sen sijaan voi arvostella sitä, miten julkiset hankinnat käytännössä toteutetaan. Julkisen hankinnan laadukas toteuttaminen ei ole helppoa, ja hankinnat tehdään usein kyseenalaisella laadulla.

Tarjouspyyntö on julkisen hankinnan keskeisin asia

Julkisten hankintojen keskeisin dokumentti on tarjouspyyntö. Tarjouspyynnön perusteella

• tarjoajat laativat tarjouksensa sisällön, ts. mitä sitoutuvat toimittamaan asiakkaalle
• valitaan voittava tarjous

Tarjouspyyntö sisältää kolme keskeistä asiaa: 

1. Kelpoisuusvaatimukset. Tarkoittaa vaatimuksia, mitkä asetetaan tarjoavalle yritykselle. Esimerkiksi jos hankittava tuote tai palvelu on sisällöltään "iso", voidaan vaatia, että tarjoava yritys on vähintään tietyn kokoinen. Tai voidaan vaatia, että tarjoavalla yrityksellä on aiempaa kokemusta samantyyppisten tuotteiden/ palvelujen toimittamisesta. 
2. Laatuvaatimukset (käytetään usein nimitystä "pakolliset vaatimukset"). Tarkoittaa vaatimuksia, mitkä asetetaan tarjotulle tuotteelle tai palvelulle. Jos hankitaan vanhusten hoivapalvelua, niin pakolliseksi resurssivaatimukseksi voitaisiin asettaa "0,7", eli 7 hoitohenkilökunnan jäsentä 10 vanhusta kohden. 
3. Vertailukriteerit. Määrittää mittarit, joiden perusteella valitaan voittaja niiden tarjousten joukosta, jotka täyttävät sekä kelpoisuusvaatimukset että pakolliset vaatimukset. Vertailukriteereissä yksi tekijä on aina hinta; lisäksi voi olla laatukriteereitä. Esimerkiksi hinnan painoarvo voi olla 70%, laatutekijä a 20%, laatutekijä b 5% ja laatutekijä c 5%. Voittaja on se, joka saa eniten pisteitä, kun eri valintakriteerien pisteet lasketaan painotetusti yhteen. 

Huomioitavaa on siis se, että 

• laatuvaatimukset määrittävät, millainen tuote tai palvelu tilataan
• voittavaa tarjousta ei valita "älyllisesti", vaan voittaja määritetään mekaanisesti laskemalla vertailukriteerien pisteitä yhteen
• ja siis se, että tarjouspyynnön sisältö - miten kelpoisuusvaatimukset, laatuvaatimukset ja vertailukriteerit on laadittu - "ratkaisee kaiken"

Käytännön huomiot osoittavat, että tarjouspyyntöjä ei useinkaan osata tehdä oikein

Julkisen hankinnan onnistumisen ratkaisee siis se, miten tarjouspyyntö on laadittu. 

Itse olen seurannut tietojärjestelmien hankintoja, ja huomannut, että tarjouspyynnöissä on paljon ongelmia. Esimerkiksi en ole nähnyt ensimmäistäkään tarjouspyyntöä - ja olen käynyt niitä läpi ehkä 200 - jossa tietojärjestelmän  käytettävyys (helppokäyttöisyys) olisi osattu laittaa tarjouspyyntöön oikealla tavalla (= että varmistettaisiin, että järjestelmän käytettävyys on riittävän hyvä). 

Oletukseni on, että myös muiden kuin tietojärjestelmien tarjouspyynnöissä on ongelmia. Jos ei olisi, niin ei pitäisi olla myöskään ongelmia tarjotuissa palveluissa, kuten vanhusten huollossa. 

Mahdollisia ongelmia voi olla kaikissa katergorioissa (kelpoisuusvaatimuksissa, laatuvaatimuksissa ja vertailukriteereissä), esimerkiksi

• määritetään kelpoisuusvaatimuksia, jotka turhaan sulkevat pois joitakin yrityksiä
• asetetaan laatuvaatimuksia, jotka ovat tarpeettomia ja tekevät toimittajien ratkaisuista turhan monimutkaisia, laaduttomia ja kalliita
• jätetään oleellisia laatuvaatimuksia asetettamatta
• vertailukriteerit asetetaan väärin 

Suuri väärinkäsitys laadun ja hinnan suhteessa

Ehkä merkittävin virhe ja väärinkäsitys, mikä tarjouspyynnöissä tehdään, on miten hinta ja laatu sisällytetään niihin.  

Ajatellaan, että jos vertailukriteereissä hinnan painoarvo asetetaan pieneksi (esim. 30%) ja laatutekijöiden painoarvo suureksi (esim 70%), niin saataisiin hyvää laatua. Tämä on täydellinen väärinkäsitys. Näin ei varmisteta laatua. 

Oikea tapa on määrittää riittävä laatu pakollisiin vaatimuksiin, ja asettaa vertailukriteereiksi pelkästään hinta (vertailukriteereissä hinnan painoarvo on 100%). Näin saadaan riittävän hyvä tuote tai palvelu edullimmalla hinnalla. 

Haasteena on sitten tietenkin usein se, mikä on riittävä laatu ja miten se määrittää. Tämän määritys onkin julkisen hankinnan aidon osaamisen mittari. 

Uusi kirja julkaistu: "Kohdemaailma-analyysi. Syvälliseen asiakasymmärrykseen heti kehityshankkeen alussa".

Uusi kirjani "Kohdemaailma-analyysi. Syvälliseen asiakasymmärrykseen heti kehityshankkeen alussa" julkaistiin 11.1.2019.

Kirjan sisällön voi tiivistää erään palautteen sanoin: ”Aivan ehdoton tapa aloittaa joku projekti, jotta voi varmistua, että kaikki puhuu jatkossa samaa kieltä ja ymmärtää asiat samalla tavalla.”

Enemmän kirjasta:

• esittelytilaisuuden videotallenne
• aiempi blogikirjoitukseni
• kustantajan Ketterät kirjat sivulta, josta kirjan voi myös tilata. 

Kohtele asiakasta samoin kuin käytettävyystestauksessa kohdellaan käyttäjää

Kohdemaailma-analyysi on menetelmä, jolla pääset nopeasti syvälliseen asiakasymmärrykseen heti kehityshankkeen alussa. Menetelmä ja siitä kertova kirja julkaistaan webinaarissa perjantaina 11.1.2019 klo 13. 

Webinaarin ilmoittautumissivulle pääset tästä (paikkoja rajoitetusti). 

-----------------------------
Seuraavassa johdatusta Kohdemaailma-analyysi -menetelmään.

1. Aluksi käytettävyystestauksesta, mistä löytyy menetelmän tausta.
2. Miksi asiakkaan ymmärtäminen ei useinkaan onnistu järjestelmäsuunnittelussa?
3. Mitä tarkoittaa "kohdella asiakasta samoin kuin käyttäjää"?

1. Käytettävyystestauksen keskeinen periaate

Käytettävyystestaus on käytettävyyssuunnittelun perinteisin menetelmä. Sen kulku pääpiirteissään on:

• lähtökohtama on kehitettävän järjestelmän jonkintasoinen prototyyppi
• pyydetään käyttäjiä testihenkilöiksi
• annetaan käyttäjälle tehtäviä, joita käyttäjän pitäisi suorittaa
• annetaan käyttäjälle ohjeistukset: 
• "Tee tehtävä parhaasi mukaan". (usein pyydetään samalla ajattelemaan ääneen)
• "Keskity omaan suoritukseesi, tehtäväsi ei ole arvioida käyttöliittymän hyvyyttä".
• "Jos et osaa tehdä tehtävää, niin vika ei ole sinussa vaan suunnitteluratkaisuissa".
• testiä seuraava suunnittelutiimi havainnoi käyttäjän suoriutumista, yrittäen ymmärtää käyttäjän suoriutumisen perusteella, mikä suunnitteluratkaisussa toimii ja mikä ei toimi
• korjataan suunnitteluratkaisut, jotka eivät näyttäneet toimivan

Käytettävyystestauksessa on siis keskeistä, että käyttäjä on pelkästään tiedon lähde. Hän toimii ainoastaan omana itsenään, kun hän yrittää tehdä tehtäviä. 

Käyttäjällä siis ei ole mitään vastuuta käyttöliittymän kehittämisestä: 

• ei analysointi- eikä jäsentämisvastuuta testin aikana
• eikä vastuuta siitä, millainen käyttöliittymä lopulta kehitetään.

Jos tämän muotoilee suunnitteluperiaatteeksi, niin se voisi kuulua: 

Suunnittelutiimi vastaa kaikesta käytettävyydestä. Käyttäjä ei mistään. 

2. Miksi asiakkaan ymmärtäminen ei useinkaan onnistu järjestelmäsuunnittelussa?

Järjestelmäkehityksessä asiakaslähtöisyys tarkoittaa usein asiakkaan vastuuttamista. Pyydetään asiakasta määrittämään vaatimuksia, esittämään toiveita, osallistumaan työpajoihin jne. 

Tämä ei yleensä vain toimi: lopputuleman laatu kun voi olla mitä tahansa. Tilanne on vähän sama kuin jos käyttäjät laitettaisiin suunnittelemaan käyttöliittymiä. (joo, tiedän, että näinkin tehdään...)

Miksi tämän tyyppinen asiakkaan osallistaminen ei toimi? 

Sen vuoksi, että on hyvin sattumanvaraista, kuinka hyvin asiakkaat pystyvät jäsentämään oikein tarpeitaan ja maailmaansa. Vaatimusten, toiveiden ym. esittäminen laadukkaasti on hyvin haastava tehtävä, johon monellakaan ei ole aidosti resursseja: ei aikaa eikä usein kiinnostustakaan. 

Laatuongelman ohella asiakkaan laittaminen tällaiseen työskentelyyn on myös eettisesti kyseenalaista. 

3. Mitä tarkoittaa "kohdella asiakasta samoin kuin käyttäjää"?

Käytettävyystestauksen periaatteen (ks. yllä) voisi muotoilla järjestelmäsuunnittelun tasolle seuraavasti: 

Suunnittelutiimi vastaa yksin siitä, että suunnitteluratkaisut ovat asiakkaan tarpeiden mukaiset. Asiakas ei ollenkaan. 

Mitä tämä tarkoittaa käytännössä? Miten pitäisi kommunikoida asiakkaan kanssa, kun halutaan ymmärtää hänen maailmaansa ja tarpeitaan? Niin että vastuu on suunnittelutiimillä, ja tuloksena on aito asiakasymmärrys?

Tähän vastaa Kohdemaailma-analyysi -menetelmä. Menetelmä - ja siitä kertova kirja - esitellään webinaarissa pe 11.1. klo 13. Tässä vielä linkki ilmoittautumissivulle. 

Mikä meni Nokian käyttöliittymissä pieleen?

Nokialla sai 1990-luvulla vallan erikoinen käyttöliittymäparadigma, jossa yhdeksi puhelinten segmentointitekijäksi otettiin erilaiset käyttöliittymät. Monet erilaiset käyttöliittymät osaltaan vaikuttivat Nokian luopumiseen puhelinbisneksestä.

Luin Risto Siilasmaan kirjan ”Paranoidi optimisti”, jossa hän kertoo kokemuksistaan Nokian hallituksessa vuodesta 2008 eteenpäin. Mukaansa tempaava, mielenkiintoinen kirja!

Ehkä merkittävin Nokian ongelma oli se, että ohjelmistokehityksen isoja ongelmia ei tuotu avoimesti esiin johdolle: ei hallitukselle, mutta ei myöskään alemmille johtoportaille. Ja kun asia selvisi, oli liian myöhäistä. 

Ohjelmistokehityksen yksi osasyy oli puhelinten käyttöliittymissä. Niihin liittyi kaksi selkeää ongelmaa:  

1. Aluksikin, puhelinten käytettävyys oli ongelmallista, käytettävyys ei ollut (läheskään) Applen tasoa. 
2. Toiseksi, Nokian eri puhelimissa oli erilaisia käyttöliittymiä. Kun Apple pystyi keskittymään yhden käyttöliittymän kehittämiseen, niin Nokian tarvitsi paljon resursseja ylläpitämään ja kehittämään monia käyttöliittymiä. 

Tässä nyt keskityn tuohon jälkimmäiseen (2) ongelmaan. Yksinkertainen peruskysymys on: 

Miksi Nokialla oli eri puhelimissa erilaisia käyttöliittymiä? 

Itse olin Nokialla Oulun yksikössä 1990-luvun loppupuolella, jolloin tämä kehitys sai alkunsa. Mitä tarkalleen tapahtui 2000-luvulla, sitä en tiedä. Mutta ainakin tilanne oli sama: erilaisia käyttöliittymiä eri puhelimissa. 

Nokialla sai 1990-luvulla valtaa sellainen ajattelu, että käyttöliittymä on yksi segmentointitekijä. Eri markkinasegmenteille suunniteltiin erilaisia ominaisuuksia sisältäviä puhelimia (sinällään järkevää). 

Mutta se, että yhdeksi segmentointitekijäksi otettiin erilaiset käyttöliittymät, oli käytettävyysmielessä tietenkin älytön ajatus. 

Monet käyttöliittymätyylit veivät siis Nokialta paljon kehitysresursseja. Lisäksi paradigmaan liittyy (ainakin) kaksi käytettävyysongelmaa:  

1. Erilaiset käyttöliittymät tarkoittivat, että eri puhelimet olivat erilaisia käyttää. Kun oli oppinut käyttämään yhtä nokialaista, ei osannut käyttää toista mallia. Ilmiö näkyi myös Nokian sisällä. Nokian omatkin työntekijät kertoivat, kuinka hankalaa oli opetella käyttämään erimallista nokialaista.
2. Erilaiset käyttöliittymät tietenkään eivät ole käytettävyydeltään saman vertaisia. Ja erityisesti alemman segmentin vähänäppäimisissä malleissa oli käytettävyysongelmia. Karrikoiden voikin sanoa, että Nokian ratkaisu konkretisoitui - toki tiedostamatta - siten, että ”köyhemmille saa kelvata huonompikin käytettävyys”. 

Lienee ilmeistä, että käytettävyysasiantuntijan näkökulmasta tilanne oli vähintään turhauttava. Varsinkin kun tätä erikoista suunnitteluparadigmaa markkinoitiin Nokian sisällä ”käytettävyydellä”. (Tämän enempää en kuitenkaan mene siihen, miten tällainen kehitys sai Nokialla vallan). 

Koin oman käytettävyysasiantuntijan roolini erittäin ristiriitaisena. Toisaalta käytettävyysasiantuntijana olin tukemassa näiden eri tyylien käytettävyyden hiomista (ja niistä tulikin kohtuullisia). Toisaalta koko ajan olin siinä ristiriitatilanteessa, että mitä paremmin tein työni, sitä enemmän välillisesti tuin tuota älytöntä monen erilaisen käyttöliittymätyylin paradigmaa. 

Risto Siilasmaa kertoo useampaan otteeseen kirjassaan, miten hän tuoreena johtoryhmän jäsenenä oli ”arka”, eikä ottanut esiin asioita, jotka häntä vaivasivat. 

Ehkä myös minä omalta osaltani olin ”arka”. Yritin kyllä viestiä asiasta Nokia sisällä, mutta en ehkä oikeille tahoille. Enkä välttämättä oikeilla tavoilla. Ongelma oli esimerkiksi se, että miten viestiä käytettävyyttä, kun johdolle oli viestitty, että vallalla ollut paradigma ikään kuin edusti käytettävyyttä? 

Kun sitten tässä tilanteessa minulle tarjottiin Oulun yliopistolta professorin tehtävän hoitamista, niin siirryin Nokialta pois. Ei mikään tavallinen ratkaisu tilanteessa, jossa Nokia oli kuumimmassa nousukierteessä.  

PS. Sen ajan avaintermi oli ”käytettävyys”, ”usability”. Tänä päivänä varmaan puhuttaisiin ”käyttäjäkokemuksesta”, ”user experience”. 

Miten parempia käytettävyyden asiantuntija-arviointeja? (ratkaisuna ei "käyttäjiä mukaan")

Olin mielenkiintoisessa seminaarissa (25.10.2018), jossa teemana oli "Käyttäjät keskiöön terveyspalvelujen suunnittelussa".

Yksi seminaarissa esille tullut asia oli käyttäjien (tässä tapauksessa lääkärien) tekemät asiatuntija-/heuristiset käytettävyysarvioinnit.

Jos olet seurannut tätä blogia (esim. tämä ja tämä) ja muita kirjoituksiani (esim. tämä, s. 61-73), niin varmaan olet huomannut, että itse en suosittele tämän tyyppistä käyttäjien osallistumista. Näen siinä niin eettiisiä kuin laadullisia ongelmia. 

Peruste käyttäjien tekemille asiantuntija-arvioinneille on luonnollisesti se, että käyttäjät tuntevat sovelluksen substanssin. Ja ajatellaan, että kun käytettävyysasiantuntijat eivät tunne sovellusaluetta, niin käyttäjien substanssitietämys toisi lisäarvoa. Vaikka tuntuu loogiselta, mutta on siis lähtökohtaisesti ongelmallinen ratkaisu; syynä siis niin eettiset kuin laadulliset syyt. 

Miten tämä saada parempia käytettävyyden asiantuntija-arviointeja? 

Aluksikin, käytettävyysasiantuntijoiden suorittamat asiantuntija-arvioinnit ovat aina tekijänsä näköisiä: arvointien tulokset vaihtelevat sen mukaan, kuka sattuu tekemään arvioinnin. Myös eri arvioijien lähestymistavat vaihtelevat. Itse olen päätynyt siihen tulokseen, että en tee heuristisia arviointeja ollenkaan; en vain näe sellaisia erityisen hyödyllisiksi. 

Oma ratkaisuni on se, että arvioinnin pohjaksi perehdyn varsin syvällisesti sovellusalueeseen. Vain sitä kautta on perusteet löytää keskeiset ja tärkeimmät käytettävyysongelmat. Oma ratkaisuni perehtyä sovellusalueeseen on kohdemaailma-analyysi: 

• tieto sovellusalueesta kerätään muutamalla haastattelulla
• sovellusalueen ymmärtäminen perustuu omalle (ei käyttäjien) ajattelu- ja jäsennystyölle
• haastatteluissa keskitytään arvioinnin kannalta oleellisiin asioihin (tavoitteena esimerkiksi ei alkuunkaan ole oppia lääkärin kliininen työ)
• arvioidaan sovelluksen käytettävyys (eikä "käyttöliittymän käytettävyys")
• yleensä 2 - 3 päivässä saa riittävän ymmärryksen (ei siis alkuunkaan niin kauan kuin ehkä kuvittelisi)
• tämän jälkeen tehdään asiantuntija-arviointi

Kohdemaailma-analyysiin perustuva asiantuntija-arviointi vie luonnollisesti enemmän resursseja kuin esim. heuristinen arviointi. Mutta väitän, että tulosten syvällisyys ja merkittävyys on aivan eri luokkaa. Toisaalta se on paljon kevyempi kuin käytettävyystestit, ja tuottaa laajemmat ja syvällisemmät tulokset. (Huom! Tämä on oma kokemukseni; minulla ei ole mitään varsinaisia tutkimustuloksia näiden väitteiden tueksi. Mielellään otan haasteen vastaan...)

PS. Kirja kohdemaailma-analyysista ilmestyy vuoden 2019 alkupuolella. (seuraa tätä blogia!)

Käyttäjäkeskeisen suunnittelun uudistettu malli

Päivitetty JFunnel 2.0 sisältää kaksi merkittävää aktiviteettia, jotka yleisesti puuttuvat tai ovat pienessä roolissa käyttäjäkeskeisen suunnittelun malleissa: (1) käyttäjäkeskeisyyden aito sitominen liiketoiminnnan tavoitteisiin sekä (2) syvällisen ymmärryksen hankkiminen kohdemaailmasta ("kehitystiimi ymmärtää paremmin asiakkaan tarpeet kuin asiakas itse"), mikä puolestaan muodostaa keskeisen perustan suunnitteluratkaisujen onnistumiselle.


Käytettävyyssuunnittelu (käyttäjäkeskeinen suunnittelu, ihmiskeskeinen suunnittelu, tai oikeammin "käytettävyysohjattu vuorovaikutussuunnittelu") on tapa suunnitella palveluja, järjestelmiä ja tuotteita, jotka ovat käytettävyydeltään (riittävän) hyviä.

Käytettävyyssuunnittelun vaiheista on erilaisia, periaatteiltaan kuitenkin samantyyppisiä malleja. Esimerkkinä ISO 9241-210, jota olen itse käyttänyt perusreferenssinä. Kuitenkin ne ovat yleensä sen verran yleisiä, toisaalta myös usein puutteellisia, kuvauksia, että mallin soveltaja joutuu pakostakin tekemään tulkintoja.

Olen kuvannut oman tulkintani käytettävyyssuunnittelusta, nimeltään JFunnel, kirjassani Navigoi oikein käytettävyyden vesillä (2010). Kuitenkin asiat ovat vuosien aikana edelleen jäsentyneet ja malli on jalostunut. Erityisesti siihen on tullut yksi hyvinkin oleellinen lisäys.

Seuraavassa kuvaan tiivistetysti päivitetyn mallin, JFunnel 2.0, määrittelemät käytettävyyssuunnittelun vaiheet. (kuvan saa klikkaamalla suuremmaksi)

0. Kohdemaailma-analyysi

Katso kuvaus lopusta. 

1. "Haluttu käytettävyyden vaikuttavuus" 

Määrittää ne liiketoiminnalliset hyödyt, joita (riittävän) hyvällä käytettävyydellä tavoitellaan. Tämä voi koostua useista eri hyödyistä. Oleellista on, että hyödyt ovat aidosti liiketoiminnasta vastaavien päätöksiä.   Samoin oleellista on, että hyödyt määritetään mittarein ja tavoitetasoin. Esimerkiksi hyötytavoite voi olla, että turhien tukipuhelujen lukumäärä putoaa 90%. 

Tämä vaihe on sellainen, joka monista muista malleista puuttuu (myös ISO 9241-210:sta). 

2. Käyttäjäryhmien määritys

Yleinen käytettävyyssuunnittelun perustehtävä: tunnistettava (tärkeimmät) käyttäjäryhmät. 

3. Käyttäjien halutut aikaansaannokset

Tämän vaiheen kohdalla useissa muissa malleissa on "käyttäjätehtävien analyysi" tms. "Halutut aikaansaannokset" korostaa sitä, että oleellisempaa on ymmärtää, mitä käyttäjien tulisi saada aikaiseksi, kuin se, miten käyttäjä käyttää järjestelmää. 

4. Käytettävyysvaatimukset

Tässä määritetään käytettävyysvaatimukset: minkä tasoinen käytettävyys pitäisi olla, jotta sillä saavutettaisiin "haluttu käytettävyyden vaikuttavuus" (vaihe 1). Ainoa toimiva tapa määrittää käytettävyysvaatimukset on perustaa ne käyttäjien suoriutumiseen. 

Käytettävyysvaatimukset tulee (luonnollisesti) määritellä mitattavasti. 

5. Vuorovaikutusratkaisujen suunnittelu

Jos vaiheet 1 - 4 ovat luonteeltaan analyyttisiä (ymmärtää käyttäjiä, ymmärtää mitä halutaan), niin tämä vaihe on luonteeltaan konstruktiivinen: suunnitteluratkaisujen tuottaminen. 

Suunnittelua ohjaavat toisaalta vaiheiden 1 - 4 tulokset, toisaalta yleiset suunnitteluohjeistot ja teknologiset rajoitukset ja mahdollisuudet. Myöhemmässä vaiheessa suunnittelua ohjaavat myös vaiheiden 6 ja 7 tulokset. 

6. Käytettävyyspalaute

Tässä vaiheessa haetaan arvioinneilla ja testeillä laadullista palautetta suunnitteluratkaisujen onnistumisesta. Parempia suunnitteluratkaisuja kehitetään ongelmakohtien ratkaisemiseksi (eli palataan vaiheeseen 5). 

7. Käytettävyyden todentaminen

Kun muodostunut käsitys, että suunnitteluratkaisu voisi olla riittävän hyvä, niin ratkaisu todennetaan todentamistesteillä. Toisin sanoen, mitataan, saavutetaanko asetetut käytettävyysvaatimukset (vaihe 4). 

Jos vaatimukset saavutetaan, niin suunnitteluratkaisu on käytettävyyden näkökulmasta valmis. Jos taas vaatimukset eivät täyty, pitää palata vaiheisiin 5 ja 6. 

8. Halutun käytettävyyden vaikuttavuuden todentaminen

Tämä voidaan todentaa vasta sen jälkeen, kun järjestelmä on ollut käytössä jo jonkin aikaa. Eli jos tavoitteeksi oli asetettu (vaihe 1), että "tukipuhelut vähenevät 90%", niin mitataan, missä määrin tämä tavoite toteutuu. 

0. Kohdemaailma-analyysi

Kohdemaailma-analyysi vaihe puuttui kokonaan Navigoi oikein käytettävyyden vesillä -kirjasta. Tämä on "erilainen" aiemmista vaiheista, koska se ei ole suoraan käytettävyyssuunnittelua. Kuitenkin se on oleellinen perusta sille, että käytettävyyssuunnittelu onnistuu. 

Kohdemaailma on se asiakkaan reaalimaailma, jota kehitettävä tuote, järjestelmä tai palvelu on suunniteltu toiminnallisesti tukemaan.  Esimerkiksi kun kehitetään yliopiston tohtorikoulutusta tukeva tietojärjestelmä, kohdemaailma on yliopiston tohtorikoulutus. Vastaavasti kohdemaailma on sairaalaan ilmoittautuminen (itseilmoittautumisjärjestelmä), lääkärien erikoistumiskoulutus (erikoistumiskoulutuksen hallintaohjelmisto) ja yrityksen toiminta (toiminnanohjausjärjestelmä). 

Kohdemaailma-analyysin tavoite on, että kehitystiimi tuntee kohdemaailman syvällisesti, "paremmin kuin asiakas itse". Vastoin kuin ehkä luulisi, tämä ei suinkaan ole mikään kohtuuton tavoite. Oma havaintoni vuosien ajalta on, että merkittävät käytettävyysongelmat johtuvat siitä, että suunnittelijoilla on ollut vajaavainen tai väärä ymmärrys kohdemaailmasta. 

Eli yleissuositus: ensin kohdemaailma-analyysi, ja vasta sitten käytettävyyssuunnittelun muut vaiheet. 

Päivitys: Kohdemaailma-analyysista on ilmestynyt kirja: https://www.ketteratkirjat.fi/kirjat/36229  

SUS (System Usability Scale) suomeksi

Olen kääntänyt joskus SUS:n (System Usability Scale) suomeksi.

Tuli yhteydenotto, jossa halutaan viitata ko. käännökseen. Laitanpa sen nyt näkyviin tähän blogiin, niin käännöksen löytää ja siihen voi viitata helpommin.

Lisätietoa SUS:sta on John Brooken alkuperäisartikkelissa "SUS - A quick and dirty usability scale", joka löytyy googlaamalla. 

PS. SUS:sta on tehty myös "positiivinen" versio P-SUS, josta olen kirjoittanut täällä. 

Hyvän mielipidekirjoituksen kaava: Miten saada mielipidekirjoitus käytettävyydestä (ja muustakin) läpi Helsingin sanomiin?

Kirjoitin Helsingin sanomiin mielipiteen 17.4.2018, ja se julkaistiin seuraavana päivänä (18.4.2018, kuva tämän kirjoituksen lopussa). Mielipidekirjoitukseni aihe on sama kuin mikä monissa aiemmissa: käytettävyys ja siihen liittyen erityisesti julkinen hankinta. Tässä tapauksessa casena on Apotti, mitä olen myös käsitellyt aiemmin niin blogissa kuin myös Hesarissa.

Tämä on 11. mielipidekirjoitukseni Hesariin (luettelo löytyy tästä), joka on julkaistu muutaman viime vuoden aikana. Suurin osa niistä käsittelee käytettävyyttä ja julkista hankintaa, mutta on myös muutama yhteiskunnallinen mielipide. Lisäksi olen kirjoittanut Hesariin kaksi vieraskynää. Kirjoitusteni läpäisyprosentti on ollut reilusti yli 50, mikä mielestäni on korkea. Tietääkseni Hesariin tulee paljon mielipidekirjoitusehdotuksia, joista vain murto-osa hyväksytään.

Tässä blogikirjoituksessa en nyt keskity käytettävyyteen, en julkiseen hankintaan enkä Apottiin - käytettävyyssubstanssi on kerrottu mielipiteessä alla. Sen sijaan tarkoitukseni on kertoa, miten kokemukseni mukaan kannattaa kirjoittaa mielipide niin, että sillä on hyvät mahdollisuudet tulla hyväksytyksi Hesariin (ja varmaan muuallekin).

Eli tässä on hyvän mielipidekirjoituksen kaavani. Voit verrata sitä tämän kirjoituksen lopussa olevaan kopioon mielipideosastelle lähettämästäni sähköpostista:

A Tekniset seikat

1. Sähköpostin otsikoksi olen yleensä laittanut yksinkertaisesti "Ehdotus mielipideosastolle" 
2. En ole yleensä kirjoittanut sähköpostiin mitään pidempää saatetta; kertonut vain, että tässä on ehdotus mielipidepalstalle (kuten tässä). Tosin kun kirjoitin graduohjemielipidettä, niin kirjoitin saatetekstiin, että ehdotuksestani tuli "vähän ”opettava”, enkä tiedä sopiiko mielipidepalstalle. Mutta harkittavaksenne kuitenkin". Ehkä kannattaa olla mieluummin vähän vaatimaton kuin korostaa itseään?
3. Oma nimi ja yhteystiedot
4. Selkeä erotin (esim. katkoviiva), josta näkee mihin saateteksti päättyy ja mistä varsinainen mielipide alkaa.
5. Kirjoitan suoraan sähköpostin runkoon, enkä tee erillistä dokumenttia. Ajattelen, että toimittajan on helpompi lukea (lyhyt) teksti suoraan sähköpostista kuin avata liitettä. 
6. Alle nimi, titteli, mitkä haluaa näkyvän mielipidekirjoituksessa ja paikkakunta.

B Aiheen valinta

1. Aiheen on oltava ajankohtainen. Olen usein omissa kirjoituksissani viitannut mielipiteen alussa johonkin edellisten päivien huomiota herättävään juttuun tai pääkirjoitukseen Hesarissa. Kuten myös tässä tapauksessa: mielipidekirjoituksessani viittasin juttuun "Vantaalle palkataan hoitajien sijaisia vakiväkeä huomattavasti kovemmalla palkalla..."   
2. Kirjoituksella pitää olla jonkin "pihvi": (poikkeava) näkökulma, jonka haluaa tuoda esille. Tässä viimeisessä kirjoituksessa otin esiin näkökulman, mitä ei suoraan sanottu jutussa mutta joka on tunnettu aiemmista uutisista. Tässä vanhemmassa kirjoituksessa toin esiin näkemyksen, jossa haastettiin pääkirjoituksen väite. 

C Kirjoittaminen

1. Pääohje: tiivistä, yksinkertaista, karsi, tiivistä, yksinkertaista ja karsi. Lopputuloksena lyhyt ja fokusoitunut juttu, jossa ei ole rönsyjä. Luultavasti joudut jättämään monta mielestäsi tärkeää näkökulmaa pois. 
2. Jos kyse on ammatillisesta asiasta, niin asiaa on kansanomaistettava. Jos toimittaja ei ymmärrä, niin tuskin julkaistaan. Hyväksy, että "oiot" tekstissä. Sisällön ei tarvitse olla tieteellisessä mielessä tarkka.  
3. Teksti pitää kirjoittaa hyvin jäsennellyksi. Perustapa tähän on, että pyörittelet, jäsentelet ja editoit tekstiä jonkin aikaa - harvoin tulee hyvää jälkeä kerralla (ainakaan minulla). Tämän viimeisen mielipiteen kirjoittamiseen minulla meni aikaa vain puolisen tuntia - ehkä johtuen siitä, että olen niin usein aiemmin kirjoittanut aiheesta. Mutta helposti lyhyenkin tekstin pyörittelyssä menee parikin tuntia. 
4. Jos kirjoittaa poliittisesta tai yhteiskunnallisesta asiasta, niin pitää pyrkiä mahdollisimman neutraaliin ilmaisuun. 
5. Loppuun olen yrittänyt laittaa poleemisen noston (tässä tapauksessa "Hankintamenettelyn puutteita ei pelastanut edes se, että lukijalle tehtiin tietojen mukaan massiivisiakin käyttäjätestejä ennen sen käyttööotttoa").
6. Itse olen ehdottanut otsikkoa ("Otsikko esim. ..."), tietäen että toimitus usein muotoilee otsikon itse. Kirjoitan otsikon aina ihan viimeisenä asiana, ja yritän muotoilla joka tapauksessa sen lyhyeksi ja iskeväksi. Tässä tapauksessa otsikkoehdotukseni otettiin vähän muotoiltuna.

Alla kopio mielipideosastolle lähettämästäni sähköpostistani. Siitä näkyy myös se, missä määrin toimitus muokkasi alkuperäistä tekstiäni.

(yllä olevaa tekstiä editoitu 24.4, tarkoituksena selkeyttää kaavaa)

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

(Sähköpostin otsikko: "ehdotus mielipidepalstalle")


hei,

alla oleva mielipide ehdolle mielipidepalstalle. 

terv. Timo Jokela
(tähän yhteystiedot)
——————————

Otsikko esim: ”Apotista tulikin vaikeakäyttöinen?"

Vantaalla on aiheuttanut närää se, että Apotti-potilastietojärjestelmän käyttöönottoa varten palkataan henkilöitä korkeammalla palkalla kuin mikä on hoitohenkilöstön palkkataso (HS 17.4.). Tätä perustellaan sillä, että "Apotin täytäntöönpano on varsin kova ponnistus, jonka onnistuminen pitää varmistaa”. 

Monissa aiemmissa yhteyksissä on sanottu, että Apotin hankinnan yksi tavoite oli ”käytettävyys”. Toisin sanoen, että Apotti-järjestelmän käyttö olisi helppo oppia. Uutisen mukaan näyttää nyt kuitenkin siltä, että järjestelmän helppokäyttöisyyteen ei aidosti uskota. 

Helppokäyttöisyyden yksi yleinen peruskriteeri on, että substanssiosaajat - terveydenhuollon järjestelmän kyseessä ollessa esimerkiksi lääkärit ja sairaanhoitajat - osaavat käyttää uuttakin järjestelmää ilman koulutusta. Jos uusi järjestelmä tarkoittaa merkittäviä muutoksia prosesseihin tai työnkulkuihin, niin koulutus voi olla perusteltua. Mutta jos järjestelmä on aidosti helppokäyttöinen, se ohjaa myös uusiin toimintatapoihin. Käyttöönoton ei missään tapauksessa pitäisi olla ”kova ponnistus”, ja sitä varten pitäisi riittää kevyehkö koulutus.  

Hyvässä tapauksessa pelko Apotin käyttöönoton haasteellisuudesta on turha. Voi olla, että Apotti on aidosti helppokäyttöinen. 

Kuitenkin Apotin kilpailutuksesta saatujen tietojen mukaan käytettävyys on huomioitu samaan tyyliin kuin monessa aiemmassa julkisessa hankinnassa. Kokemus osoittaa, että nykyiset hankintatavat eivät takaa helppokäyttöisyyttä. Käytettävyys on ollut ”tärkeä” kriteeri monessa aiemmassakin julkisessa hankinnassa, ja epäonnistuttu. Hyvänä esimerkkinä pääkaupunkiseudun matkakortinlukijan hankinta, jonka käytettävyys tunnetusti epäonnistui. Hankintamenettelyn puutteita ei pelastanut edes se, että lukijalle tehtiin tietojen mukaan massiivisiakin käyttäjätestejä ennen sen käyttööotttoa. 

Timo Jokela, FT, dosentti
Helsinki