Käytettävyyskurssi 9.-10.3.2016

Olen pitämässä Talentum Eventsin järjestelmää Käytettävyys ja käyttäjäkeskeinen suunnittelu -kurssia yhdessä Aapo Puskalan kanssa.

Tietojärjestelmien käytettävyysongelmat: miten ottaa oppia tuotekehityksestä?

Tietojärjestelmien käytettävyysongelmien yksi keskeinen syy on se, että vastuu vaatimuksista, tarpeiden jäsentämisestä ja suunnitteluratkaisujen oikeellisuudesta sälytetään asiakkaille. Mallia pitäisi ottaa tuotekehityksestä, jossa vastuu asiakkaan ymmärtämisestä ja suunnitteluratkaisujen toimivuudesta on luonnollisesti  yksinomaan aina kehittävällä yrityksellä. (Vai voiko Nokia syyttää käyttäjiä siitä, että heidän puhelimiensa käytettävyys ei toiminut?)

Aito asiakaslähtöinen suunnittelu ymmärretään hyvin usein väärin. Ajatellaan, että se tarkoittaa asiakkaan osallistumista suunnitteluprosessiin. Ja että kun asiakas on mukana määrittely- ja kehittämistyössä, niin se itsessään takaa, että suunnittelun laatu paranee ja saadaan korkealuokkainen lopputulos.

On kuitenkin kriittistä, millä tavoin, missä rooleissa ja millä vastuulla asiakas on mukana. Tässä tehdään kaksi yleistä virhettä. 

1. Laitetaan asiakas sellaisiin rooleihin, joissa tällä ei ole edellytyksiä tuottaa hyvää laatua. Tällaisia ovat tehtävät, jotka eivät ole asiakkaan ydinosaamista ja joihin tällä ei ole aitoja edellytyksiä, resursseja tai motivaatiota. 
2. Vastuutetaan asiakasta niistä tuotoksista, joita tämä tuottaa näissä väärissä rooleissa.

Jo järjestelmämäärittelyn peruslähestymistapa on aidon asiakaslähtöisyyden vastakohta: pyydetään asiakasta kertomaan vaatimuksia, toiveita, mielipiteitä ja näkemyksiä kehitettävästä järjestelmästä. 

Muita ongelmallisia tapoja ovat esimerkiksi ne, joissa asiakkaan edustajat laitetaan tekemään määrittelyjä tai suunnittelua työpajoissa tai arvioimaan suunnitteluratkaisuja, prototyyppejä, rautalankamalleja tms.

Aidossa asiakaslähtöisyydessä asiakas on ainoastaan sellaisissa rooleissa, jossa hän voi tuottaa laadukasta tietoa kehittämistyöhön – oman ammattinsa, työnsä ja työpaikkansa asiantuntijana – ja jossa asiakasta ei laiteta minkäänlaiseen vastuuseen kehittämistyön laadusta.

Käytännössä tämä tarkoittaa ainoastaan kahta asiakkaan roolia: 

1. Asiakas on tiedon lähteenä työstään ja kehittämiskohteesta – esimerkiksi lääkäri kertoo työstään ja sairaalan toiminnasta. 
2. Asiakas – erityisesti käyttäjä – on kehitettävän järjestelmän tai sen prototyyppien testikäyttäjänä.

Vastuullinen asiakaslähtöisyys on sitä, että järjestelmää tai tuotetta kehittävä yritys ottaa kaiken vastuun kaikesta suunnittelutyössä, asiakastarpeen perusymmärryksestä lähtien. Aidossa asiakaslähtöisyydessä suunnittelun lähtökohtana on

• kehitystiimin syvällinen ymmärrys asiakkaan työstä ja asiakkaan maailmasta
• kehitystiimin omassa tulkinnassa siitä, mitä asiakas aidosti tarvitsee  sekä toteutuksen kehittämisen laadusta
• kaiken kaikkiaan kehitystiiminvastuunotto ajattelusta koko kehityshankkeen ajan.

Keskeinen kysymys sitten tietenkin on se, että miten kehitystiimi pääsee sisälle asiakkaan maailmaan ja saa syvällisen ymmärryksen siitä? Päinvastoin kuin usein ajatellaan, tämän pystyy tekemään yllättävänkin nopeasti. Oleellista on vain tehdä se toimivalla tavalla. Väitän, että nykyisin käytössä olevat menetelmät (aktivitettikaaviot, vuokaaviot, prosessikuvaukset, tietovirtakaaviot jne.) eivät pureudu oleelliseen. 

Itse olen hakenut ratkaisua uudesta ajattelutavasta: menetelmästä nimeltään kohdemaailma-analyysi. Katso lisää tästä.  

Uusin Sytyke-lehti (4/ 2015) keskittyy käytettävyyteen, käyttäjäkokemukseen ja esteettömyyteen

Uusin Sytyke-lehti (4/ 2015) keskittyy käytettävyyteen, käyttäjäkokemukseen ja esteettömyyteen. Lehti on katsottavissa täältä.

Lehden editoreina olivat Eija Kalliala, Matti Vuori ja minä.

Lehti sisältää monta mielenkiintoista artikkelia:

• 3 Pääkirjoitus • Matti Vuori
• 4 Verkkosivustojen käytettävyys uusiin korvin • Tapio Haanperä, Sirpa Riihiaho
• 6 Käytettävyys avoimen lähdekoodin ohjelmistokehityksessä – haasteita ja mahdollisuuksia • Mikko Rajanen
• 8 Käytettävyyden vaikuttavuus – käytettävyyden lenkki bisnekseen • Timo Jokela
• 10 Käyttökokemustavoitteiden hyödyntäminen – Case konttinostureiden etäohjauskonsoli • Hannu Karvonen, Eija Kaasinen, Hanna Koskinen
• 13 Sytyke ry:nVaikuttavin opinnäytetyö 2014–2015-kilpailunvoittaja 
• 14 Käytettävyyttä terveysteknologiaan – viranomaisvaatimukset ja markkinoilla menestyminen • Terhi Holappa
• 18 Tilit selviksi – ikäihmisten digipalveluissa on vielä kehittämistä • Aulikki Uusitalo-Kasvio
• 20 Missä laajuudessa käyttäjät mukaan? Ohjenuorana kehittäjien ja käyttäjien välinen sosiaalinen etäisyys • Mikael Johnson
• 22 Palveluiden käytettävyyden ja esteettömyyden perustelu ja edistäminen • Henry Haglund
• 24 Digitaaliset palvelut ja käyttökokemus it-tradenomien opetuksessa • Niina Kinnunen
• 26 Kolumni: Kuutamolla

Oma artikkelini otsikko siis Käytettävyyden vaikuttavuus – käytettävyyden lenkki bisnekseen. 

Tiivistelmä: Ohjelmiston hyvä käytettävyys on joskus todella tärkeää, joskus vähemmän olennaista. Kuinka hyvää käytettävyyttä tarvitaan ja kuinka paljon käytettävyyden suunnitteluun kannattaa panostaa, riippuu halutusta käytettävyyden vaikuttavuudesta.

Ilmainen Käytettävyys tietojärjestelmien hankinnassa -verkkokurssi katsottavissa 13.11.2015 asti (PÄÄTTYNYT)

Osa 1: Johdanto

• Miten hankinnoissa on lähdettävä kehittämään käytettävyyden aitoa huomioimista?
• Miten käytettävyys hankinnoissa eroaa käytettävyydestä tuotekehityksessä?

Osa 2: Käytettävyys
• Mitä on käytettävyys - ja mitä se ei ole?
• Jos halutaan hyvää käytettävyyttä, mitkä suunnitteluratkaisut ovat kriittisimpiä?
• Miten käyttäjäkokemus eroaa käytettävyydestä?

Osa 3: Hankinta
• Mitä ovat tarjouspyynnön keskeiset elementit käytettävyyden (laadun) näkökulmasta?
• Miten järkevän toimittajan kannattaa toimia?
• Käytettävyys pakollisissa vaatimukset vs. vertailukriteereissä?
• Mikä on ainoa käytettävyyden takaava menettely tarjouspyynnössä? 

Osa 4: Johtopäätökset
• Mikä yllättävä käytettävyystoimenpide nousee keskeiseksi hankinnoissa?
• Minkä yllättävän käytettävyysasian määrittäminen on kriittisintä?
• Mikä kolmas näkökulmaa pitää ottaa huomioon?
• Mitä käytännön käytettävyystoimenpiteitä hankkijan olisi osattava?

KATSO KURSSI TÄSTÄ

"Apotin ongelmat näkyivät jo tarjouspyynnössä"

Lähetin ao. kirjoituksen ehdolle Helsingin sanomien mielipidepalstalle jo n. kuukausi sitten. Sitä ei kuitenkaan julkaistu, mutta julkaisempa sen sitten tässä. 

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

CGI:n Matti Häkkinen ihmettelee (HS 7.9.15), kannattaako Apotista maksaa 65 miljoonaa enemmän 2,5 pisteen takia. Hyvä kysymys, mutta ei yllättävä. 

Jo Apotin tarjouspyyntö kertoo, että valintaprosessissa saattoi käydä köpelösti kahdella tavalla: (1) maksetaan kovaa hintaa sellaisesta laadusta, jota ei oikeasti tarvita tai (2) saadaan sattumanvaraista laatua. Toki voidaan saada hyvääkin laatua ja oikealla hinnalla - mutta vain, jos on hyvä tuuri.  

Apotin tarjouspyynnössä tehtiin sama virhe, mikä monessa muussakin julkisessa hankinnassa: valintaperusteissa laatutekijöille annettiin suuri painoarvo. Apotin valintakriteereissä laatutekijöiden painoarvo 60 prosenttia ja hinnan painoarvo oli 40 prosenttia. Laadun painottaminen valintakriteereissä ei kuitenkaan takaa laadukasta lopputulosta eikä oikeaa hintaa. Valituksi voi aina tulla vaihtoehto, joka saa joltakin laadun osa-alueelta ”nollan” - saadaa siis surkeaa laatua. Tai sitten voidaan maksetaan kovaa hintaa ylilaadusta. 

Laadun iso painoarvo valintaperusteissa viestii usein myös sitä, että hankkija ei ole selvittänyt, millaista laatua hän aidosti tarvitsee. 

Jos julkisessa hankinnassa halutaan hyvää laatua, hinnan pitäisi olla ratkaiseva valintakriteeri - siis painoarvo lähellä 100 prosenttia - niin nurinkuriselta kuin se ehkä kuulostaakin. Hankkijan pitäisi keskittyä määrittämään, mikä on riittävän hyvä laatutaso, ja laittaa se tarjouspyynnön pakollisiin vaatimuksiin. Ei ole helppo tehtävä, mutta paljon hyödyllisempi kuin monimutkaisten vertailukriteerien määrittäminen ja vertailujen suorittaminen. 

On täysin mahdollista, että Apotissa maksetaan 65 miljoonaa turhasta laadusta. Tai sitten ei. Apotissa käytetyt hankintakriteerit eivät takaa laatua eivätkä sitä, että laadusta maksetaan oikea hinta. 

Käytettävyys/ esteettömyysartikkelin Sytyke-lehteen?

Hyvä käytettävyyden/ esteettömyyden asiantuntija, 

Kutsun sinua (tai kollegoitasi) kirjoittamaan artikkelin vuoden viimeiseen Sytyke-lehteen (http://www.sytyke.org/sytyke-lehti/). Lehden teema on ”Käytettävyys ja esteettömyys”. Lehti ilmestyy 3.12.2015. 

Kaikki aiheeseen liittyvät kirjoitukset ovat tervetulleita. Erityisesti arvostamme tutkimuspohjaisia artikkeleita. Artikkeli on mainio tilaisuus esittää tutkimustuloksia suomeksi ja kevyemmällä formaatilla kuin tieteellisillä foorumeilla. 

Ohjeet lehden kirjoittajalle ovat osoitteessa http://www.sytyke.org/sytyke-lehti/ohjeet-lehden-kirjoittajalle/. 

Lehti on 28-sivuinen, josta noin 22 sivua on varattu asiantuntija-artikkeleille kuvineen. Siihen mahtuu artikkelien pituudesta riippuen 5 - 10 artikkelia. Artikkelien joukkoon saattaa tulla muutamia Sytykkeen ja yhteistyökumppaneiden vajaan sivun kokoisia ilmoituksia. 

Artikkelit, kuvat ja kirjoittajatiedot tulisi lähettää minulle (timo.jokela@gmail.com) ja/ tai lehden päätoimittaja Eija Kallialalle (eija.kalliala@sytyke.org) ti 27.10. mennessä. Artikkeleille tehdään kielihuoltokierros. 

Toivomme, että tartut tähän tilaisuuteen. Käytettävyys ja esteettömyys -teemaisia lehtiä ei Suomessa usein julkaista. ilmoitathan artikkelisi otsikon tai aihepiirin meille 5.10. mennessä! 

terveisin, 

Timo Jokela 
puh: 040 5118250 
Eija Kalliala 
puh: 040 525 1761

Käytettävyys ja käyttäjäkeskeinen suunnittelu -kurssi 10.-11.9.2015

Järjestäjänä Talentum Events.

Katso tarkemmat tiedot täältä: http://talentumevents.fi/kaytettavyys/

Apotissa tehdään julkisten hankintojen perusvirhe

HS (21.3.2015) Apotista: "Tarjouksia vertailtaessa hinta ratkaisee 40 prosenttia. Muut perusteet liittyvät esimerkiksi laatuun, käytettävyyteen ja jatkokehityksen avoimmuuteen."

Jo tämän uutisen perusteella voidaan sanoa, että Apotin hankinnassa tehdään julkisten hankintojen perusvirhe. Selitän, mikä tämä on ja miksi se on virhe tässä videossa.

Ilmainen verkkokurssi: "Käytettävyys tietojärjestelmien hankinnassa"

Pidän otsikon mukaisen kurssin huhtikuun 2015 alussa. Tarkempaa tietoa ja ilmoittautuminen kurssille TÄSTÄ.

"Helppokäyttöisiä järjestelmiä pitää osata vaatia"

Kirjotinpa taas käytettävyysasiasta Hesariin: http://www.hs.fi/mielipide/a1427082794483 (24.3.2015)

Ei mitään erityisen uutta, mutta kun oli sopiva kirjoitus, mihin reflektoida.

Tiivistettynä:

"Monesti hankkijat ajattelevat ratkaisun olevan se, että käyttäjät otetaan mukaan hankintaprojektiin ja kysytään heidän mielipiteitään.

Ensimmäinen askel kohti aitoa käyttäjäystävällisyyttä on ymmärtää, että tällaiset triviaalit toimenpiteet eivät alkuunkaan ole vastaus tietojärjestelmien hankinnan todellisiin haasteisiin"