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