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