Käytettävyysatastrofi, jota käytettävyyden määritelmä ei tunne

Jeff Sauro siteraa blogissaan Gerry McGovernia, joka määrittelee (käytettävyys)katastrofiksi tilanteen, jossa käyttäjä luulee saavuttaneensa oikean aikaansaannoksen mutta ei olekaan saavuttanut sitä.

Mielenkiintoinen tähän liittyvä näkökulma on se, että käytettävyyden ISO-määritelmä ei kata tällaista tilannetta, koska siinä ei ole attribuuttia "koetulle tuloksellisuudelle".

Olenkin standardointityöryhmissä ottanut esiin, että kun käytettävyyden määritelmää tarkastellaan uudelleen, nykyisiä attribuutteja (tuloksellisuus, tehokkuus, miellyttävyys) laajennettaisiin koetulla tuloksellisuudella ja myös koetulla tehokkuudella.

Katso Jeff Sauron blogi ja kommenttini siihen: http://www.measuringusability.com/blog/ui-disasters.php

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

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

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. 

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

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

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.

ISO 9241-210 ilmestynyt suomeksi (ja on parempi kuin alkuperäinen englanninkielinen...)

ISO 9241-210 on julkaistu suomeksi. Itse (Timo) tein käännöksen "leipätyön"; MetStan kanssa sitten stilisoitiin se.

Sen verran käännösprosessista, että alkuperäisessä englannin kielisessä versiossa oli useampi kohta, jotka olivat epäselviä tai eivät oikein loogisia. Kommunikoin standardin editoijan Tom Stewartin kanssa, ja hänkin huomasi puutteellisuuksia ja virheitä tekstissä.

Nämä epäselvät asiat on huomioitu suomenkielisessä käännöksessä. Ja sen vuoksi voi sanoa, että suomenkielinen versio on parempi kuin alkuperäinen!

Mutta katso myös kirja Navigoi oikein käytettävyyden vesillä! Siinä on paikkailtu standardin ongelmakohtia* ja on sen vuoksi vieläkin parempi...


*Nämä ongelmakohdat ovat siis minun jäsennystäni. Katso tämän blogin aiemmat kirjoitukset.

Timon vieraskynä Helsingin Sanomissa 9.11.2011

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

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

Mitä eroa käytettävyystestillä ja fokusryhmällä?

seuraava linkki valaisee hauskasti asian: http://someslightlyirregular.com/2011/08/you-say-potato/

Käytettävyysseminaarin oikea linkki

onkin tämä: http://www.sytyke.org/toiminta

Käytettävyysseminaarin oikea linkki

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

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

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

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

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

Käytetttävyyssuunnittelun perustandardi ISO 9241-210 ilmestynyt suomeksi

ISO 9241-210 kuvaa käytettävyyssuunnittelun ("Vuorovaikuittesten järjestelmien käyttäjäkeskeisen suunnittelun") keskeiset käsitteet, periaatteet ja aktiviteetit. Sisältää esimerkiksi käyttäjäkokemuksen määritelmän. Korvaa aiemman, hyvin tunnetun standardin ISO 13407.

Standardia saa SFS:ltä: http://sales.sfs.fi/servlets/ProductServlet?action=showquicksearch&keywords=9241-210&x=24&y=15 (standardithan pitää ostaa).

Standardi on periaatteessa suunnattu "laite- ja ohjelmistokehityksen sekä uudelleensuunnittelun prosesseista vastaaville henkilöille", mutta on ehdottoman suositeltavaa peruslukemista myös käytettävyysasiantuntijoille ja käyttöliittymäsuunnittelijoille.

Olin itse mukana valmistelevassa työryhmässä. Vaikka standardi on siis tärkeää peruslukemista alan ammattilaisille, kannattaa ottaa huomioon, että tämä(kin) standardi on osaltaan kompromissi,  ja sitä tulee tarkastella myös kriittisesti. Standardi sisältää hyvin keskeisiä asioita, mutta omasta mielestäni siihen jäi myös ongelmakohtia (käyn läpi standardia blogissa http://iso9241-210.blogspot.com/).

- Tein itse standardin peruskäännöstyön, jota sitten viimeisteltiin MetStan kanssa. Palautetta käännöksestä otan mielelläni vastaan, ja kysymyksiä saa esittää.

Älä kysy näitä asioita käyttäjiltä

Yksi käytettävyysalan guruja on Jared Spool. Persoonallinen kaveri ja tosi hyvä esiintyjä. 

Kävin - tai käytiin porukalla - hänen kurssillaan joskus Nokialla ollessani joskus ammoin (vuonna 1995), aiheena paperiprotoilu. Se kurssi opetti paljon. Väitän muuten, että paperiprotoilulla oli ratkaiseva merkitys sille, että aikanaan Nokia oli käytettävyydessä markkinoiden ykkönen (ks. slide show paperiprotoilusta). 

Nyt Jared kirjoittaa aiheesta "kolme kysymystä, mitä ei tulisi kysyä käyttäjätutkimuksessa": http://www.uie.com/articles/three_questions_not_to_ask/

Ja ottaa esiin seuraavat asiat: 

• älä kysy käyttäjältä tulevaisuudesta
• älä kysy, kuinka käyttäjä suunnittelisi jonkun toiminnon (oma huomautus: tämä kiusaus tulee kovin helposti käytettävyystesteissä tai palavereissa käyttäjien kanssa)
• älä kysy siten, että tarjoat valmista ehdotusta syyksi 

Nämä kaikki hyviä pointteja. Mutta eivät kaikki välttämättä uusia. Osallistuin CHI-konferenssin tutoriaaliin käyttäjien haastattelusta vuonna 1996. Pitäjänä Eileen Isaac. Hän toi esiin osittain samat asiat. Eli älä kysy käyttäjiltä:

• mitä he tekisivät hypoteettisissa tilanteissa (vastaa tuota "älä kysy käyttäjältä tulevaisuudesta")
• kuinka usein käyttäjät tekevät asioita
• milloin he tekivät viimeksi jonkin asian
• paljonko he pitävät jostain asiasta absoluuttisella skaalalla

Ja minä lisäisin tähän vielä oman mausteeni: 

• kun kysyt, älä tyydy sellaiseen vastaukseen, jota et ymmärrä

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

("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!

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

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

Mikä on toimiva tapa ottaa käyttäjät mukaan järjestelmänkehitysprojektiin? Asia tuli taas esiin neuvottelussa asiakkaan kanssa.

Aluksikin, on mielestäni myytti, että järjestelmänkehitysprojekteissa eivät käyttäjät olisi mukana, eikä käyttäjiä kuunnella. Kyllä minun havaintoni on se, että projekteissa kannetaan huolta siitä, että käyttäjät ovat mukana, käyttäjiltä kysellään jne. 

Silti tulokset ovat mitä ovat. Käytettävyys tökkii enemmän tai vähemmän.

Kyse ei ole siitä, että käyttäjät eivät olisi mukana, tai että käyttäjiltä ei kyseltäisi. Jopa väitän, että syyt käytettävyysongelmiin ovat osaltaan juuri siinä, että käyttäjät ovat mukana - mutta siinä "väärässä" roolissa, missä ovat tänä päivänä. 

Tänä päivänä käyttäjät otetaan mukaan projekteihin rooleissa, jotka eivät toimi. 

MIkä on sitten ongelma käyttäjien rooleissa? Tiivistäisin asian siten, että ongelma on se, että käyttäjille annetaan vastuu tarpeitteinsa ja työnsä jäsentämisestä. 

Oman työn ja tarpeiden jäsentäminen on vaativaa työtä. Ja väitän, että käyttäjiä ei aidosti kiinnosta laittaa omia resurssejaan sellaiseen asiaan, joka ei ole heidän varsinaista työtään. Toki kyse on myös osaamisesta - työn jäsentäminen vaatii oman ammattitaitonsakin.

Työ jäsentäminen on haastavaa, "aivoresursseja" kuluttavaa työtä. Ja sellaiseen työhön pitää aidosti pinnistellä. Jos nyt tätä tekee "velvollisuudesta jonkin verran", niin ei ihme, jos lopputulos ei ole laadukas. 

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

Esimerkki: Otetaanpa esimerkiksi se, että joku olisi kehittämässä uutta sähköpostiohjelmaa. 

Kaikki me olemme sähköpostiohjelman käyttäjiä; joillekin voi olla hyvinkin keskeinen työkalu. Niinkuin minullekin. 

Mutta jos joku tulisi haastattelemaan minulta tyyliin "millaisen sähköpostiohjelman haluat?", "mitä toiminnallisuuksia siinä pitäisi olla?", "miten nykyistä voisi parantaa?", "pitäisikö olla sitä ja tätä ominaisuutta?" jne. niin voin suoraan sanoa, että ei kiinnosta alkaa pohtia vastauksia tällaisiin kysymyksiin. Minua kiinnostaa hyvä sähköpostiohjelma, mutta sen kehittäminen ei ole minun päänsärkyni. 

Minä uskon, että samalla tavalla suhtautuisi haastatteluun moni teistä lukijoistakin. (Vai olenko väärässä?)

Joka tapauksessa, jos kehittäjät perustavat suunnittelunsa sille, mitä minä sanon tällaisessa haastattelussa, niin heikoilla ovat. 

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

Nyt kuitenkin kokemukseni mukaan järjestelmänkehityshankkeissa käyttäjiä laitetaan juuri tämän tyyppisiin rooleihin. Jäsentämään omaa työtään. Mikä taas ei ole heidän työtään. 

Itse teen työkseni käyttäjien työn jäsennystä, mutta kun juuri sähköpostin kehittäminen ei erityisesti ole minun työtäni, niin resurssieni laittaminen siihen - ei kiitos!

Eli yhteenvetona näkemykseni ja suositukseni on: Käyttäjien työn jäsennys on järjestelmän kehityksestä vastaavien työtä, ei käyttäjien. Sen sijaan käyttäjille sopiva rooli on olla tiedon lähteenä. 

Mitä tämä tarkoittaa menetelmällisesti, siitä myöhemmin enemmän. 

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

PS. Tätä näkemystä tukee myös tuleva väitöskirja terveydenhuollon järjestelmien käytettävyydestä, jossa muun muassa tutkittiin sitä, missä rooleissa lääkärit haluaisivat olla mukana järjestelmien kehittämisessa. Mutta enpä kerro tästä enempää; Johanna Kaipio väittelee aiheesta Aalto-yliopistossa myöhemmin syksyllä (itse toimin esitarkastajana ja sitä kautta minulla etukäteistietoa)

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

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

1. "... tarvitaan selkeä ja helppokäyttöinen työkalu. Siirtyminen ... tasolta seuraavalle tulee olla helppoa..."

Tukeeko toimittaja edellä kuvattua ominaisuutta?

Vastaus:___"

2. ".... (toiminnallisuuden) tulee olla helposti ymmärrettävässä ja käsiteltävässä muodossa ja raporttien 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?

Käyttäjäkokemuksen määritelmä ei osu ihan kohdalleen

Käyttäjäkokemuksen keskeinen ja aika uusi (2010) määritelmä ISO 9241-210:ssa kuuluu seuraavasti (epävirallinen suomennos; standardin suomennus pitäisi ilmestyä piakkoin; ks. myös blogi koko standardista http://iso9241-210.blogspot.com):

"Käyttäjäkokemus: Henkilön havainnot ja vasteet, jotka ovat seurausta tuotteen, järjestelmän tai palvelun käytöstä ja/tai ennakoidusta käytöstä". 

Tämä on tarkennettu huomatuksilla: 

"HUOM. 1   Käyttäjäkokemus sisältää kaikki käyttäjien tunteet, uskomukset, mieltymykset, fyysiset ja psyykkiset vasteet, käyttäytymiset ja aikaansaannokset, jotka ilmenevät ennen käyttöä, käytön aikana ja käytön jälkeen.

HUOM. 2   Käyttäjäkokemus on seurausta tuotemerkin imagosta, ulkonäöstä, toiminnallisuudesta, järjestelmän suorituskyvystä, järjestelmän vuorovaikutuskäyttäytymisestä ja avustavista ominaisuuksista, käyttäjän aiemmasta kokemuksesta johtuvasta sisäisestä ja psyykkisestä tilasta, asenteista, taidoista, persoonallisuudesta sekä käyttötilanteesta.

HUOM. 3   Käytettävyys käyttäjien henkilökohtaisten tavoitteiden näkökulmasta tulkittuna voi sisältää sen tyyppisiä aisti- ja tunnenäkökulmia, joita tyypillisesti liitetään käyttäjäkokemukseen. Käytettävyyskriteereitä voidaan käyttää arvioimaan käyttäjäkokemuksen joitakin näkökulmia."

-------------------
Olin työryhmässä, jossa valmisteli tätä standardia ja vaikuttamassa myös määritelmän muotoiluun. Nyt jälkikäteen ajateltuna, mielestäni määritelmässä ei ihan osuttu kohdalleen. 

Tuo määritelmä tekee käyttäjäkokemuksesta liian "kaiken kattavan". Erityisesti jos lukee sen, mitä  HUOM 1:ssä sanotaan. Siinä erityisesti kohta "Käyttäjäkokemus sisältää... käyttäjien... aikaansaannokset,..." on se, joka ei semanttisesti oikein istu hyvin kokemus-sanaan. Aikaansaannoshan tarkoittaa jotain konkreettista, mitä käyttäjä saavuttaa. Vaikkapa jos tilaa lentolipun verkosta, niin aikaansaannos on se lentolippu. 

Käyttäjäkokemus terminä viittaa kuitenkin semanttisesti subjektiiviseen, psyykkiseen asiaan (kokemus). Ei lentolippu (aikaansaannos) ole itsessään kokemus. Sen sijaan lipun tilaamiseen voi liittyä kokemuksia ("olipa helppoa!" tms.). 

Yhteenvetona: Käyttäjäkokemuksen määritelmä on tehty turhan laajaksi ISO 9241-210 määritelmässä. Termit pitäisi määritellä niin, että määritelmä vastaa semanttisesti itse termiä. Nyt "kokemukseen" liitetään asioita, jotka eivät ole "kokemuksia". Olisi selkeämpää, että käyttäjäkokemus määriteltäisiin kattamaan vain "kokemuksellisia" asioita. Aikaansaannokset katetaan hyvin käytettävyyden määritelmässä (ISO 9241-11). 

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

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

Älä laita tietokonetta leikkimään ihmistä

Kävin viikolla toisessakin mielenkiintoisessa tilaisuudessa, kuntamarkkinoilla http://www.kuntamarkkinat.fi/

Siellä esiteltiin mm. suomi.fi -sivustoa. Sivustossa siellä täällä näkyy ihmishahmo (hahmolla oli jokin nimikin, en nyt muista sitä): 

Tällainen suunnitteluratkaisu ei edusta käyttäjäystävällisyyttä. Ei ole suositeltavaa, että tietokone "leikkii" ihmistä. Suuri osa käyttäjistä vain ei pidä tällaisista ideoista. On se hahmo sitten aidomman näköinen ihminen tai vaikka windows-tyyppinen paperiliitin: 

Tämä ei ole (pelkästään) oma näkemykseni, vaan sitä tukevat tutkimukset. 

Muunmuassa Shneidermannin käyttöliittymäalan perusoppikirjassa http://www.pearsonhighered.com/educator/academic/product/0,3110,0321537351,00.html on oma alalukunsa "ei - ihmisen kaltaisesta" (nonanthropomorphic) suunnittelusta. Tutkimukset kertovat, että ihmisen kaltaiset suunnitteluratkaisut "amused some, but annoyed many". 

 Ei ole siis suositeltavaa, että suunnitellaan tietokone "leikkimään" ihmistä. 

Älä usko mitä käyttäjät sanovat (paitsi joskus)

Olin kuuntelemassa mielenkiintoista esitystä PKT:n aamuseminaarissa http://www.pkt.fi/asiantuntijapalvelut/aamu-matinea/aamu-matineasyyskuu/, pitäjänä Sirpa Juutinen, PricewaterhouseCoopers. 

Sirpan aihe sivusi asiakastarpeiden ymmärtämistä. Sirpa sanoi muunmuassa että 

• "pitää pystyä hahmottamaan asiakkaan tarve... asiakas voi odottaa asiaa b, mutta pyytää palvelua a, joka ei johda b:hen" (ei ehkä ihan sanatarkasti mutta suunnilleen näin)

Pitää siis nähdä asiakkaan sanojen taakse, ja tarjota oikeaa palvelua tai ratkaisua.

Tämä sama pätee tismalleen myös käyttäjien tarpeiden ymmärtämiseen. Käyttäjät voivat 

• sanoa jotain, joka ei ole se tarve
• tai voivat olla sanomatta jotain, joka on se tarve
• ja joskus ehkä sitten niinkin, että se mitä käyttäjät sanovat, on se tarve. 

Keskeistä käytettävyysosaamista on se, että selvittää käyttäjän tarpeet, riippumatta siitä miten käyttäjä ne ilmaisee. 

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

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

• http://hankikaytettavyytta.blogspot.com/2011/08/jhs-suosituksen-kaytettavyysvaatimusesi.html 
• http://hankikaytettavyytta.blogspot.com/2011/09/kaytettavyysvaatimukset-tulee-olla.html)

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

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: 

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

kirjoituksia Hanki käytettävyyttä! -blogissa

Olen viime aikoina kirjoitellut Hanki käytettävyyttä! -blogiin, http://hankikaytettavyytta.blogspot.com/

Kyseisen blogin erityinen näkökulma on käytettävyyden varmistaminen tietojärjestelmien hankinnoissa. Mutta siinä on ehkä kiinnostavaa käytettävyysasiaa yleisemminkin. Viime kirjoitukset käsittelevät käytettävyysvaatimuksia ja käytettävyyden validointia.

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

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ä

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

JHS-suositus "173 ICT­palvelujen 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?

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.

muutama käytettävyysongelmaharjoite

Seuraavassa muutama suunnitteluongelma, joihin vastikään törmäsin (kun siis olin täyttämässä ko. lomakkeita). Mitä ongelmia, ja miten ratkaisisit?

a)

tarkempi kuva yo. dialogista:

b)

tarkempi kuva yo. dialogista:

c)