keskiviikko 23. marraskuuta 2011

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

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. 



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


torstai 17. marraskuuta 2011

Älä laske klikkauksia!

Niiiiiiiin usein kuulee väitettävän, että hyvä verkkosivusto on sellainen, jossa tarvitsee klikata vähän.

Lienee kuitenkin useimmille alan ammattilaiselle selvää, että näin ei ole. Yksi (verkko-) käytettävyyden peruskirjan nimikin sanoo, mistä on ensisijaisesti kyse: Don't make me think!

Nyt asia on vahvistettu tutkimuksellakin: älä laske klikkauksia vaan mittaa aikaa! Ks. http://www.measuringusability.com/blog/click-clock.php

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

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)

tiistai 15. marraskuuta 2011

ISO 9241-210: miten lukea käytettävyyden perusstandardia?


Käytettävyyden standardit tulivat esiin SIGCHI Finlandin järjestelmässä seminaarissa 10.11.2011, sen loppupaneelin yhteydessä. 

Seminaarissa käyttämässäni spontaanissa yleisöpuheenvuorossa kerroin lyhyesti standardien synnystä. Kuitenkin puheenvuoroni oli lyhyt, ja myöhemmin tuli esiin, että sen perusteella saattoi jäädä vajaavainen kuva standardien syntymisestä. 

Kerroin puheenvuorossani jotain, miten miten standardiryhmä valmistelee standardia: että työryhmässä keskustellaan, väitellään, tehdään kompromisseja, editorin rooli on iso jne. 

Kuitenin se jäi kertomatta, että standardia kehittävä työryhmä ei suinkaan päätä yksin standardin sisällöstä. Ennen hyväksymistä standardiluonnokset käyvät läpi kansalliset lausuntokierrokset, joiden perusteella tehdään tarvittaessa muutoksia. 

Mutta standardin tekstiluonnokset ja -muotoilut tuottaa siis työryhmä, ja erityisesti niiden editori. Ja teksti tietenkin jää aika paljon elämään, vaikka kuinka palautetta tulisi kommenttikierrosten aikana. 

Kun käänsin ISO 9241-210 standardia (Vuorovaikutteisten järjestelmien käyttäjäkeskeinen suunnittelu), niin sen alkuperäisessä englanninkielisessä versiossa oli useampi kohta, joka ei ollut ymmärrettävä tai looginen. Niissä kohdin otin yhteyttä ko. standardin editoriin, joka itsekin huomasi monessa kohdin ongelmia (hankalia ilmaisuja, puuttuvia sanoja, suoranaisia virheitä jne.). Otin sitten nämä huomioon käännöksessä. 

Tätä kautta ajateltuna 9241-210:n suomenkielinen käännös on parempi kuin alkuperäinen englanninkielinen...

Yhteenvetona: Kun lukee standardeja, niin seuraavia näkökulmia kannattaa ottaa huomioon: 
  • standardit ovat kompromissien ja äänestysten tulos; eivät siis edusta "totuutta"
  • kuitenkin niissä kumuloituu laajan kansainvälisen asiantuntijakaartin asiantuntemus ja osaaminen
  • jotkut asiantuntijat saavat äänensä kuulumaan ja vaikuttamaan paremmin; toiset (ehkä oikeammassakin olevat) voivat joutua antamaan periksi 
  • tekstien muotoiluun (saattaa) vaikuttaa yhden henkilön (editorin) näkemys
Eli standardeja toisaalta kannattaa lukea kunnioituksella, toisaalta kriittisellä silmällä. Esimerkiksi tuo ISO 9241-210 on mielestäni ehdotonta peruslukemista kaikille alan ihmisille.


PS. Olen siis kirjoittanut kirjan Navigoi oikein käytettävyyden vesillä. Se on minun vuosien varrella kumuloitunut näkemykseni käyttäjäkeskeisestä suunnittelusta, ja siinä on paikattu niitä asioita ISO 9241-210:ssä, joihin minun "kriittinen silmäni" on iskenyt. 


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


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.

keskiviikko 9. marraskuuta 2011

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

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

tiistai 1. marraskuuta 2011

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

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

Paikka: Haaga-Helia, Ratapihantie 13, Pasila, Helsinki. Luokka 2209
Aika: to 10.11.2011 klo 9:30 - 11:45 (- 12:00)

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

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

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

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