keskiviikko 21. joulukuuta 2016

Matkakortinlukija, osa 8: HSL:n selitys OK-näppäimelle

Edellisessä videossa arvioin, että matkakortinlukijan OK-näppäin on sen vuoksi, että halutaan tehdä toisen matkustajan lisääminen helpoksi. HSL:n mukaan OK-näppäimen tausta on kuitenkin virhevalintojen vähentäminen.

Mistä tässä on lopulta kyse, siitä alla olevassa videossa (4 min 34 s):




Edellisen osan (7) voit katsoa täältä
Seuraavan osan (9) voit katsoa täältä.


PS. Piti aloittaa kysymyksen "Miksi tuloksena käytettävyysongelmia vaikka tehdään paljon käytettävyystyötä?" käsittely jo nyt, mutta jätän sen joululomien jälkeen. 

PPS. Saat ilmoituksen sarja uusista osista liittymällä postituslistalle!

perjantai 16. joulukuuta 2016

Matkakortinlukija. Osa 7: Yhtä nopeaksi kuin entinen ottamalla turha näppäily pois

Tämän uudenkin lukija olisi voinut suunnitella sellaiseksi, että kahden näppäilyn sijasta tarvitaan vain yksi näppäily niin kuin on vanhassa lukijassa.

Videolla kerrotaan, miksi mahdollisesti oli päädytty kahden näppäilyn ratkaisuun sekä esitetään pari yhden näppäilyn ratkaisuideaa. 





Edellisen osan (6) voit katsoa täältä
Seuraavan osan (8) voit katsoa täältä.

Huom! Saat ilmoituksen sarja uusista osista liittymällä postituslistalle!

tiistai 13. joulukuuta 2016

Matkakortinlukija. Osa 6: Käyttöliittymäongelmat, joilla menetetään hyvän perusratkaisun etu

Uudessa matkakortinlukijassa on oikea järjestys: ensin valitaan, sitten maksetaan, niin kuin osassa 5 totean.

Kuitenkin tämä etu menetetään käyttöliittymän suunnitteluongelmilla. Niistä tarkemmin alla olevassa videossa.




Edellisen osan (5) voit katsoa täältä
Seuraavan osan (7) voit katsoa täältä.

Huom! Saat ilmoituksen sarja uusista osista liittymällä postituslistalle!

torstai 8. joulukuuta 2016

Matkakortinlukija. Osa 5: Hyvä piirre: oikea järjestys

On matkakortinlukijassa hyviäkin suunnitteluratkaisuja. Tässä videossa käyn läpi yhden niistä.

Videon pituus n. 2,5 minuuttia.



Edellisen osan (4) voit katsoa täältä
Seuraavan osan (6) voit katsoa täältä.

Huom! Saat ilmoituksen sarja uusista osista liittymällä postituslistalle!

keskiviikko 7. joulukuuta 2016

Matkakortinlukija. Osa 4: Miksi case matkakortinlukija? (välivideo)

Tämän videosarjan tekeminen lähti omasta käyttökokemuksesta, josta ajattelin kertoa.

Tästä nyt tuli vähän laajempi kuin ajattelin. Se, että analyysin kohteena on tavallaan myös HSL, ei ole itse tarkoitus. Vastaavia tapauksia on paljon muitakin julkisissa IT-hankinnoissa. Tämä matkakortinlukijaesimerkki vain on niin konkreettinen, helppo ja ymmärrettävä.

Videon pituus n. 1,5 minuuttia.




Edellisen osan (3) voit katsoa täältä
Seuraavan osan (5) voit katsoa täältä.

Huom! Saat ilmoituksen sarja uusista osista liittymällä postituslistalle!

maanantai 5. joulukuuta 2016

Matkakortinlukija. Osa 3: Millaista käytettävyystyötä matkakortinlukijan kehitystyössä?

Kerroin aiemmissa osissa, että matkakortinlukijaa on käytettävyystestattu paljon.

Ainakin näin on sen suunnitelman perusteella, joka aikoinaan esitettiin hankkeen käytettävyystyön tarjouspyyntöasiakirjoissa.

Tässä videossa käyn läpi matkakortinlukijan kehitystyön hankintaa sekä käytettävyystestaussuunnitelmaa. Video on hieman pitempi kuin muut, n. 7 minuuttia.



(videossa on jonkin verran äänen vaihtelua, pienistä äänitysongelmista johtuen)

Sarjan muita osia pääset katsomaan ruudun oikean reunan "Blogiarkiston" linkeistä, marras-joulukuu 2016.

Edellisen osan (2) voit katsoa täältä
Seuraavan osan (4) voit katsoa täältä.

Huom! Saat ilmoituksen sarja uusista osista liittymällä postituslistalle!

torstai 1. joulukuuta 2016

Matkakortinlukija. Osa 2: "Matkakortinlukijaa osaa käyttää, jos samalla kuvaa videota"

Kun aloin käyttää pääkaupunkiseudun paikallisliikenteen matkakortinlukijaa, niin pitkään luulin, että siitä puuttuu yksi tärkeä ominaisuus. Olin suoraan sanottuna aika ihmeissäni: miten kyseinen ominaisuus voi puuttua?

Siitä tuli idea, että otan videon lukijan käytöstä ja teen käytettävyysanalyysin. Videota ottaessa sitten paljastuikin, että kyllä tuo "puuttuva" ominaisuus lukijassa onkin.

Kyseessä on suunnitteluratkaisu, jota voi pitää ihan perustason käytettävyysvirheenä. Siitä seurauksena tämän osan 2 otsikko: "Matkakortinlukijaa osaa käyttää, jos samalla kuvaa videota" (kesto runsaat 3 minuuttia)



Edellisen osan (1) voit katsoa täältä
Seuraavan osan (3) voit katsoa täältä.

Huom! Saat tiedon seuraavista videoista ilmoittautumalla postituslistalle!



tiistai 29. marraskuuta 2016

Matkakortinlukija. Osa 1: Massiivia käytettävyystestejä ja käytettävyys pettää?

Pääkaupunkiseudun lähiliikenteessä on ollut jonkin aikaa käytössä uusi matkakortinlukija. Lukijassa on mitä selviä, jopa ihan perustason käytettävyysongelmia (toki vahvuuksiakin). 

Erityisen mielenkiintoisen tapauksesta tekee se, että käytettävyysongelmia on, vaikka matkakortinlukijaa on käytettävyystestattu paljon, jopa 100 käyttäjän massatesteillä (näin ainakin kerrotaan aikoinaan julkaistussa tarjouspyynnössä).

Aloitan matkakortinlukijan käytettävyysanalyysin. Analyysi koostuu lyhyistä, muutaman minuutin videopätkistä. 

Laitteen käytettävyyden lisäksi analysoin tarjouspyyntöä: tavasta, miten hankkeessa on käytettävyyttä pyritty varmistamaan. Analyysissa tulen osoittamaan, että itse asiassa on ihan loogista, että hankinnassa käytetty tapa ei todellakaan takaa käytettävyyttä. 

Alla analyysin osa 1: "Tästä kyse" (vajaan 4 minuutin video).








Seuraavan osan (2) voit katsoa täältä.

Huom! Saat tiedon seuraavista videoista ilmoittautumalla postituslistalle!


maanantai 12. syyskuuta 2016

"Gradun tekeminen on yksinkertaista" -video-ohjeita!

Olen kirjoitellut tässä blogissa - ja muissa foorumeissa - erityisesti käytettävyydestä sekä julkisista hankinnoista.

Nyt kesän (2016) ajattelin ottaa fokukseen myös ohjeet gradujen tekemiseen. Olen ohjannut yli 50 gradua, ja seurannut niiden tekemistä. Havaintoni on, että graduja usein ajatellaan liian "hienoina" ja niitä lähdetään ajattelemaan ja tekemään liian vaikeasti. Gradun tekeminen on kuitenkin periaatteessa yksinkertainen asia.

Toteutusajatukseni on antaa ohjeita lyhyiden videoiden muodossa.

Elokuun lopulla (27.8.2016) osui sopivasti osui silmään Helsingin sanomien mielipidesivulla gradun tekemisen tuskasta kertova mielipidekirjoitus. Siihen sitten kirjoitin vastineeksi alla olevassa kuvassa näkyvän kirjoituksen, julkaistiin 30.8.2016.

Tuo kirjoitus mielestäni sisältää gradun keskeiset asiat. Käyn ohjeen tarkemmin läpi videossa. Olen tehnyt on jo myös yhden yksityiskohtaisemman ohjeen: millainen on hyvä otsikko.

Jatkan näiden ohjeiden tekemistä syksyn 2016 aikana. Jos kiinnostaa saada sähköposti-ilmoitus uusista ohjeista, niin postituslistalle pääsee tästä.


sunnuntai 24. huhtikuuta 2016

Mitä on aito asiakaslähtöisyys?

MiitIT (entinen Hetky, Helsingin tietojenkäsittely-yhdistys) piti vuodenvaihteessa 2014-15 kirjoituskilpailun aiheesta Miten pelastamme Suomen ICT-alan? Kirjoitukseni vastuullisesta asiakaslähtöisyydestä voitti 2. palkinnon.

Linkki kirjoitukseen vanhentui ym. nimenmuutoksen johdosta, minkä vuoksi tallensin jutun omaan arkistooni.

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

Mitä on aito asiakaslähtöisyys?


Ison terveydenhuollon tietojärjestelmiä kehittävän ohjelmistoyrityksen johtaja ehdotti eräässä seminaarissa ratkaisuna alan järjestelmien käytettävyysongelmiin: "Kehittämistyöhön tarvitaan mukaan osaavampia käyttäjiä". Hänen johtopäätöksensä oli, että järjestelmien ongelmien syynä ovat hankkeissa mukana olevat "osaamattomat käyttäjät".

Tämä on esimerkki yleisestä ajattelusta Suomessa ja muuallakin, jossa asiakas- ja käyttäjälähtöisyys ymmärretään täysin väärin. Se näkyy myös tuloksissa. Terveydenhuollon järjestelmät on yksi esimerkki, ja sama näkyy käytännössä melkein jokaisella työpaikalla. Ja on oletettavaa, että jokin meni tässä pieleen aikoinaan myös Nokialla.

Aidon asiakaslähtöisyyden lähtökohta on, että kehityshankkeissa ei koskaan ole osaamattomia käyttäjiä, ainoastaan osaamatonta suunnittelua. Jos tämä aidosti ymmärrettäisiin Suomessa, olisi suomalaisilla yrityksillä iso kilpailuetu kansainvälisesti.

Aito asiakas- ja käyttäjälähtöinen suunnittelu ymmärretään säännönmukaisesti väärin. Ajatellaan, että se tarkoittaa asiakkaan osallistumista suunnitteluprosessiin. Ja että kun asiakas on mukana kehittämistyössä, suunnittelun laatu paranee ja saadaan korkealuokkainen lopputulos.

Aidossa asiakaslähtöisyydessä asiakkaan tehtävänä on ainoastaan tuottaa laadukasta tietoa kehittämistyöhön.

On kuitenkin kriittistä, millä tavoin, missä rooleissa ja millä vastuulla asiakas on mukana kehitystyössä. Tässä tehdään kaksi yleistä virhettä. Ensiksi, 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. Toiseksi, 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 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 siinä roolissa, 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 roolia: 1) Asiakas on tiedon lähteenä työstään ja kehittämiskohteesta – esimerkiksi lääkäri kertoo työstään ja sairaalan toiminnasta ja 2) asiakas – erityisesti käyttäjä – on kehitettävän järjestelmän tai sen prototyyppien testikäyttäjänä.

Nykyinen tapa tehdä asiakaslähtöisyyttä usein on vastuuta pakoilevaa. "Tarvitaan osaavampia käyttäjiä" tarkoittaa käytännössä samaa, kuin että ongelmat ovat asiakkaan syytä. 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 kehittämiskohteesta, omassa tulkinnassa siitä, mitä asiakas aidosti tarvitsee  sekä toteutuksen kehittämisen laadusta; kaiken kaikkiaan vastuunotto ajattelusta koko kehityshankkeen ajan.

Suomen ICT-alalla tarvittava muutos on päästä pois pakoilevasta asiakaslähtöisyydestä kohti vastuullista ajattelua. Huonoksi osoittautunutta ratkaisua puolustetaan usein tyyliin: "mutta kun asiakas sanoi, että...". Ollaan jo pitkällä, kun yrityksissä ymmärretään, että tällainen on pahin selitys, mihin kehitystiimi voi vedota.
------

PS. Jos haluat tietoa siitä, miten käytännössä ollaan aidosti asiakaslähtöisiä, klikkaa tästä!

maanantai 7. maaliskuuta 2016

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.

keskiviikko 27. tammikuuta 2016

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